Re: [openstack-dev] [policy] AWS IAM session

[Devdatta Kulkarni]

+1

I spent some time recently studying IAM models of AWS and GCP.
Based on this I had created following post comparing and summarizing the
two models at high-level:

http://devcentric.io/2017/07/13/comparing-iam-models-of-aws-and-gcp/

Thought of sharing it here as it may help with big-picture comparison of
the two models.

Best regards,
Devdatta


On Wed, Oct 4, 2017 at 11:12 AM, Kristi Nikolla  wrote:

> +1
>
> --
>   Kristi Nikolla
>   Software Engineer @ massopen.cloud
>   kri...@nikolla.me
>
> On Wed, Oct 4, 2017, at 10:08 AM, Zane Bitter wrote:
> > On 03/10/17 16:08, Lance Bragstad wrote:
> > > Hey all,
> > >
> > > It was mentioned in today's keystone meeting [0] that it would be
> useful
> > > to go through AWS IAM (or even GKE) as a group. With all the recent
> > > policy discussions and work, it seems useful to get our eyes on another
> > > system. The idea would be to spend time using a video conference/screen
> > > share to go through and play with policy together. The end result
> should
> > > keep us focused on the implementations we're working on today, but also
> > > provide clarity for the long-term vision of OpenStack's RBAC system.
> > >
> > > Are you interested in attending? If so, please respond to the thread.
> > > Once we have some interest, we can gauge when to hold the meeting,
> which
> > > tools we can use, and setting up a test IAM account.
> >
> > +1, I'd like to attend this.
> >
> > Also I highly recommend
> > http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/ over the
> > actual AWS docs as a compact reference.
> >
> > - ZB
> >
> > > Thanks,
> > >
> > > Lance
> > >
> > > [0]
> > > http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-10-03-18.00.log.html#l-119
> > >
> > >
> > >
> > >
> > > 
> __
> > > 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
> > >
> >
> >
> > 
> __
> > 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
>
> __
> 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
>
__
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] [all][deployment] Deployment Working Group (DWG)

[Devdatta Kulkarni]

This is a great initiative.

Coming from Solum - a project that in on the fringes with regards to user
adoption [1][2], I feel that one of the things that
can help in increasing the adoption is deployment tooling available for
operators. If there is a standardized way to introduce
a project in their OpenStack setups, it is possible that operators would
try it.

Related to the work that would be produced by the group, what is the
thought around where would deployment artifacts live?
Within each individual project's repository? As part of a single deployment
project?

Also, are there any documents with information about constructing
deployment artifacts that we can refer to currently?

Regards,
Devdatta

[1] https://www.dropbox.com/s/jzkuimcc12w3iju/solum-interest-prod.png?dl=0

[2]
https://www.dropbox.com/s/nrlov1w4hn3cv6u/solum-interest-testing.png?dl=0



On Tue, Mar 14, 2017 at 3:31 PM, Emilien Macchi  wrote:

> OpenStack community has been a welcoming place for Deployment tools.
> They bring great value to OpenStack because most of them are used to
> deploy OpenStack in production, versus a development environment.
>
> Over the last few years, deployment tools project have been trying
> to solve similar challenges. Recently we've seen some desire to
> collaborate, work on common topics and resolve issues seen by all
> these tools.
>
> Some examples of collaboration:
>
> * OpenStack Ansible and Puppet OpenStack have been collaborating on
>   Continuous Integration scenarios but also on Nova upgrades orchestration.
> * TripleO and Kolla share the same tool for container builds.
> * TripleO and Fuel share the same Puppet OpenStack modules.
> * OpenStack and Kubernetes are interested in collaborating on configuration
>   management.
> * Most of tools want to collect OpenStack parameters for configuration
>   management in a common fashion.
> * [more]
>
> The big tent helped to make these projects part of OpenStack, but no
> official
> group was created to share common problems across tools until now.
>
> During the Atlanta Project Team Gathering in 2017 [1], most of current
> active
> deployment tools project team leaders met in a room and decided to start
> actual
> collaboration on different topics.
> This resolution is a first iteration of creating a new working group
> for Deployment Tools.
>
> The mission of the Deployment Working Group would be the following::
>
>   To collaborate on best practices for deploying and configuring OpenStack
>   in production environments.
>
>
> Note: in some cases, some challenges will be solved by adopting a
> technology
> or a tool. But sometimes, it won't happen because of the deployment tool
> background. This group would have to figure out how we can increase
> this adoption and converge to the same technologies eventually.
>
>
> For now, we'll use the wiki to document how we work together:
> https://wiki.openstack.org/wiki/Deployment
>
> The etherpad presented in [1] might be transformed in a Wiki page if
> needed but for now we expect people to update it.
>
> [1] https://etherpad.openstack.org/p/deployment-pike
>
>
> Let's make OpenStack deployments better and together ;-)
> Thanks,
> --
> Emilien Macchi
>
> __
> 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
>
__
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

[openstack-dev] [Solum] PTL Candidacy for Pike

[Devdatta Kulkarni]

Hi,

I would like to submit my candidacy to continue as PTL of Solum for
the Pike cycle.

Solum (https://wiki.openstack.org/wiki/Solum) is a big tent project that
supports
building, testing, and deploying applications on OpenStack starting from
applications' source code. Applications are built as Docker containers and
deployed using Heat. Application containers are stored in Glance or Swift
(configurable).

Looking back at the Ocata cycle, some of the highlights for our team have
been:
- adding kolla-ansible role [1] and kolla container [2] for Solum
  (Many thanks to Wei Cao for spearheading this effort)
- completing Ocata goal of removing incubated Oslo libraries
- extending our core contributor team [3]

The key focus areas for the Pike cycle include:
- finding an alternative for nova-docker in our devstack setup
- completing the work that we started on adding support for building
applications into VM images
- making it easy for operators to configure and use different build and
deploy options that are supported within Solum

You might remember, we have been using nova-docker as the Virt driver
in our devstack setup. However, nova-docker is being retired [4].
So it is important that we find a replacement that can work in our devstack
setup.
We have been looking at Zun as this replacement [5]. In this cycle I hope
we can finish this work, thus removing our dependence on nova-docker.

One of our contributors has been working on adding support
to build applications into VM images [6].
You can find the details about this use-case and approach
in his thesis [7]. I hope that we are able to complete this work in this
cycle.
This will give Solum the ability to build and deploy applications as VM
images in addition to Docker containers.

Lastly, we should continue working on the Python 3.5 support [8],
which has been approved as the community-wide goal for this cycle.

If you are interested in Solum feel free to reach out to us here, or on
Solum IRC channel
(#solum on chat.freenode.net).

Regards,
Devdatta Kulkarni

[1] https://review.openstack.org/#/c/402225/
[2] https://review.openstack.org/#/c/355408/
[3]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104699.html
[4]
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109387.html
[5] https://review.openstack.org/#/c/416224/
[6] https://review.openstack.org/#/c/336570/
[7]
https://gitlab.com/ablu/bachelorthesis/builds/9259804/artifacts/file/build/Bachelor%20Thesis%20Erik%20Schilling.pdf
[8] https://etherpad.openstack.org/p/solum-python35-goal
__
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] [tc][solum] is solum-infra-guestagent an unmaintained project?

[Devdatta Kulkarni]

Hello Michael, Steve,
Thanks again to both of you for providing patches to remove oslo-incubator
code from solum-infra-guestagent.

As I mentioned earlier in this thread, I will probably propose to remove
this repository from official Solum repositories. I had it on this week's
IRC meeting agenda, but folks were probably returning from Barcelona so the
meeting did not take place.

I know that the Ocata goal acknowledgement deadline is November 17th. I
will do the acknowledgement patch to openstack/governance before that
stating the current state of Solum repositories wrt to the goal. FYI, we
have converted solum repo already and python-solumclient has had patches
proposed. We had not yet worked on solum-infra-guestagent, but thanks to
both of you, solum-infra-guestagent will now satisfy the goal (really
appreciate the patches). If Solum team agrees, we will remove
solum-infra-guestagent repository from official repos so that it won't
impact any future community wide goals.

Regards,

Devdatta

On Fri, Nov 4, 2016 at 7:00 PM, Steve Martinelli 
wrote:

> bump, still hoping to get feedback on this
>
> On Fri, Oct 28, 2016 at 1:23 AM, Steve Martinelli 
> wrote:
>
>> When reviewing the projects necessary for the ocata community-wide goal,
>> (to remove old oslo-incubator code [1]) I noticed that solum-infra-guest
>> agent has had *very* few commits, 13 in total [2]. Almost half of which
>> were project cleanup type changes that all projects did. The last patch of
>> significance was over 2 years ago (Sept 2014).
>>
>> I'm inquiring as to the status of the project, and what we should do
>> about it? It's still being maintained by the good will of some community
>> members, but it's eating up time nonetheless.
>>
>> [1] https://etherpad.openstack.org/p/ocata-goal-oslo
>> [2] https://github.com/openstack/solum-infra-guestagent/commits/master
>>
>
>
> __
> 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
>
>
__
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] [tc][solum] is solum-infra-guestagent an unmaintained project?

[Devdatta Kulkarni]

Hi Steve,

Your observation is correct.

Solum team had created solum-infra-guestagent repository to investigate the
idea of a build agent for building applications.
However the work in that direction has not progressed in a while.

So it should be okay to remove solum-infra-guestagent repo from official
governance.
I will discuss this with Solum team in our irc meeting next week and submit
a patch to remove this repo from project-config.

Thanks,
Devdatta


On Fri, Oct 28, 2016 at 12:23 AM, Steve Martinelli 
wrote:

> When reviewing the projects necessary for the ocata community-wide goal,
> (to remove old oslo-incubator code [1]) I noticed that solum-infra-guest
> agent has had *very* few commits, 13 in total [2]. Almost half of which
> were project cleanup type changes that all projects did. The last patch of
> significance was over 2 years ago (Sept 2014).
>
> I'm inquiring as to the status of the project, and what we should do about
> it? It's still being maintained by the good will of some community members,
> but it's eating up time nonetheless.
>
> [1] https://etherpad.openstack.org/p/ocata-goal-oslo
> [2] https://github.com/openstack/solum-infra-guestagent/commits/master
>
> __
> 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
>
>
__
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

[openstack-dev] [Solum] Nominating Zhu Rong for Solum core

[Devdatta Kulkarni]

Hi team,

I would like to propose Zhu Rong (irc: zhurong) to be included as Solum
core.

Zhu Rong has been very active in different parts of Solum over several
months now.
His primary contribution has been moving Solum to use Oslo libraries,
thereby
making our project satisfy one of the project-wide goals suggested
by TC for this cycle [1]. He has also been deeply involved in guiding
and contributing to the work on Solum's horizon dashboard, which was
started by
Swati Dewan as part of her Outreachy internship this summer.
Zhu Rong also actively participates on Solum IRC channel, regularly attends
IRC meetings,
and provides great feedback on patches.

You can find Zhu Rong's activity here:

http://stackalytics.com/?module=solum-group_id=zhu-rong
http://stackalytics.com/?module=solum-dashboard_id=zhu-rong

Please respond with your votes.

Regards,
Devdatta

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101348.html
__
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

[openstack-dev] [Solum] PTL candidacy

[Devdatta Kulkarni]

Hi,

I would like to submit my candidacy to continue as PTL of Solum for Ocata
cycle.

In Newton cycle we made progress in several key areas. Here are the
highlights.

1) We completed work on our Horizon dashboard. It is now possible to perform
   all languagepack and app operations through the dashboard. I would like
to
   acknowledge and thank Swati Dewan and Zhu Rong for spearheading this
work.

2) We continued building and experimenting with different options for doing
app builds
   and deployments. In Mitaka cycle we had worked on a feature that enabled
Solum to
   perform app deployments in tandem with existing CI systems such as
Jenkins that can
   do app builds.
   In Newton, following new ideas were investigated:
   - Building applications as VM images and deploying them (thanks Erik
Schilling)
   - Building applications as Unikernels (thanks shivaSR, mvle)
   - Building applications as Docker containers and deploying to VMs
(CoreOS) (thanks Wei Cao)
   We also completed the feature that enables application build and deploy
upon receiving github
   triggers by Solum.

   You can find screencasts demonstrating these features on Solum wiki
   (https://wiki.openstack.org/wiki/Solum), under "Resources" section.

3) We gained several new contributors, some of whom are on their way to
becoming cores.

For the Ocata cycle, some of the ideas that we can pursue together include:
- Making it easy for operators to configure and use different build and
deployment options
- Adding support to deploy applications to container orchestration systems
- Support for using public Docker images, in addition to Solum
languagepacks, to build
  applications

Along with these, we need to keep working on and improving our
documentation, test coverage,
and installation tooling. (If you are interested in helping out with any of
these, please reach out to our team on IRC (#solum on chat.freenode.net)).


Best regards,
Devdatta Kulkarni
__
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] [tc] persistently single-vendor projects

[Devdatta Kulkarni]

Hi,

As current PTL of one of the projects that has the team:single-vendor tag,
I have following thoughts/questions on this issue.

- Is the need for periodically deciding membership in the big tent primarily 
stemming
from the question of managing resources (for the future design summits and 
cross-project work)?
If so, have we thought about alternative solutions such, say, using the 
team:diverse-affiliation
tag for making such decisions? For instance, we could say that a project will 
get
space at the design summit only if it has the team:diverse-affiliation tag? 
That way, projects
are incentivized to purse this tag/goal if they want to participate in the 
design summit.
Also, adding/removing tag might be simpler than trying to get into big tent 
again (say, after a project
has been removed and then gains diverse affiliation afterwards and wants to 
participate in the
design summit, would they have to go through big tent application again?).

- Another issue with using the number of vendors as a metric 
to decide membership in big tent is that it rules out any project which may be 
independently started in the open (not by any specific vendor, but by a team of 
independent contributors),
and which is following the 4 opens, to be a part of the big tent.

- About diversity -- as Flavio has suggested on this thread, participating in 
Outreachy is a good option.
We have done it in Solum. However, that does not necessarily help with 
obtaining the diverse-affiliation
tag as defined currently (since Outreachy participants are students and not 
necessarily affiliated with
any vendor).

Regards,
Devdatta



From: Amrith Kumar 
Sent: Wednesday, August 3, 2016 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

To Steven's specific question:

> If PTLs can weigh in on this thread and commit to participation in such a
> cross-project subgroup, I'd be happy to lead it.

I would like to participate and help get this kind of a group going.

-amrith


> -Original Message-
> From: Steven Dake (stdake) [mailto:std...@cisco.com]
> Sent: Tuesday, August 02, 2016 11:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Responses inline:
>
> On 8/2/16, 8:13 AM, "Hayes, Graham"  wrote:
>
> >On 02/08/2016 15:42, Flavio Percoco wrote:
> >> On 01/08/16 10:19 -0400, Sean Dague wrote:
> >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
>  Thierry, Ben, Doug,
> 
>  How can we distinguish between. "Project is doing the right thing,
> but
>  others are not joining" vs "Project is actively trying to keep people
>  out"?
> >>>
> >>> I think at some level, it's not really that different. If we treat
> them
> >>> as different, everyone will always believe they did all the right
> >>> things, but got no results. 3 cycles should be plenty of time to drop
> >>> single entity contributions below 90%. That means prioritizing bugs /
> >>> patches from outside groups (to drop below 90% on code commits),
> >>> mentoring every outside member that provides feedback (to drop below
> >>>90%
> >>> on reviews), shifting development resources towards mentoring / docs /
> >>> on ramp exercises for others in the community (to drop below 90% on
> >>>core
> >>> team).
> >>>
> >>> Digging out of a single vendor status is hard, and requires making
> that
> >>> your top priority. If teams aren't interested in putting that ahead of
> >>> development work, that's fine, but that doesn't make it a sustainable
> >>> OpenStack project.
> >>
> >>
> >> ++ to the above! I don't think they are that different either and we
> >>might not
> >> need to differentiate them after all.
> >>
> >> Flavio
> >>
> >
> >I do have one question - how are teams getting out of
> >"team:single-vendor" and towards "team:diverse-affiliation" ?
> >
> >We have tried to get more people involved with Designate using the ways
> >we know how - doing integrations with other projects, pushing designate
> >at conferences, helping DNS Server vendors to add drivers, adding
> >drivers for DNS Servers and service providers ourselves, adding
> >features - the lot.
> >
> >We have a lot of user interest (41% of users were interested in using
> >us), and are quite widely deployed for a non tc-approved-release
> >project (17% - 5% in production). We are actually the most deployed
> >non tc-approved-release project.
> >
> >We still have 81% of the reviews done by 2 companies, and 83% by 3
> >companies.
>
> By the objective criteria of team:single-vendor Designate isn't a single
> vendor project.  By the objective criteria of team:diverse-affiliation
> your not a diversely affiliated project either.  This is why I had
> suggested we need a third tag which accurately 

Re: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt

[Devdatta Kulkarni]

Hi Sudipta,

There is another approach you can consider which does not need any changes to 
Nova.

The approach works as follows:
- Save the container image tar in Swift
- Generate a Swift tempURL for the container file
- Boot Nova vm and pass instructions for following steps through cloud init / 
user data
  - download the container file from Swift (wget)
  - load it (docker load)
  - run it (docker run)

We have implemented this approach in Solum (where we use Heat for deploying a 
VM and
then run application container on it  by providing above instructions through 
user_data of the HOT).

Thanks,
Devdatta


-


From: Sudipta Biswas 
Sent: Wednesday, July 27, 2016 9:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][rfc] Booting docker images using nova libvirt
  
Premise:

While working with customers, we have realized:

- They want to use containers but are wary of using the same host kernel for 
multiple containers.
- They already have a significant investment (including skills) in OpenStack's 
Virtual Machine workflow and would like to re-use it as much as possible.
- They are very interested in using docker images.

There are some existing approaches like Hyper, Secure Containers workflows 
which already tries to address the first point. But we wanted to arrive at an 
approach that addresses all the above three in context of OpenStack Nova with 
minimalist changes.


Design Considerations:

We tried a few experiments with the present libvirt driver in nova to 
accomplish a work flow to deploy containers inside virtual machines in 
OpenStack via Nova.

The fundamental premise of our approach is to run a single container 
encapsulated in a single VM. This VM image just has a bare minimum operating 
system required to run it.
The container filesystem comes from the docker image.

We would like to get the feedback on the below approaches from the community 
before proposing this as a spec or blueprint.


Approach 1

User workflow:

1. The docker image is obtained in the form of a tar file.
2. Upload this tar file in glance. This support is already there in glance were 
a container-type of docker is supported.
3. Use this image along with nova libvirt driver to deploy a virtual machine.

Following are some of the changes to the OpenStack code that implements this 
approach:

1. Define a new conf parameter in nova called – 
base_vm_image=/var/lib/libvirt/images/baseimage.qcow2
This option is used to specify the base VM image.

2. define a new sub_virt_type = container in nova conf. Setting this parameter 
will ensure mounting of the container filesystem inside the VM.
Unless qemu and kvm are used as virt_type – this workflow will not work at this 
moment.

3. In the virt/libvirt/driver.py we do the following based on the sub_virt_type 
= container:

- We create a qcow2 disk from the base_vm_image and expose that 'disk' as the 
boot disk for the virtual machine.
 Note – this is very similar to a regular virtual machine boot minus the fact 
that the image is not downloaded from
glance but instead it is present on the host.


- We download the docker image into the /var/lib/nova/instances/_base directory 
and then for each new virtual machine boot – we create a new directory 
/var/lib/nova/instances/ as it's and copy the docker filesystem 
to it. Note – there are subsequent improvements to this idea that could be 
performed around the lines of using a union filesystem approach.
- The step above allows each virtual machine to have a different copy of the 
filesystem.
- We create a 'passthrough' mount of the filesystem via libvirt. This code is 
also present in the nova libvirt driver and we just trigger it based on our 
sub_virt_type parameter.

4. A cloud init – userdata is provided that looks somewhat like this:

runcmd:
  - mount -t 9p -o trans=virtio share_dir /mnt
  - chroot /mnt /bin/

The command_to_run is usually the entrypoint to for the docker image.

There could be better approaches to determine the entrypoint as well (say from 
docker image metadata).


Approach 2.

In this approach, the workflow remains the same as the first one with the 
exception that the
docker image is changed into a qcow2 image using a tool like virt-make-fs 
before uploading it to glance, instead of a tar file.

A tool like virt-make-fs can convert a tar file to a qcow2 image very easily.

This image is then downloaded on the compute node and a qcow2 disk is 
created/attached to the virtual machine that boots using the base_vm_image.


Approach 3

A custom qcow2 image is created using kernel, initramfs and the docker image 
and uploaded to glance.  No changes are needed in openstack nova. It boots as a 
regular VM.

Changes will be needed in image generation tools and will involve few 
additional tasks from an operator point of view.


I look forward to your comments/suggestions on the above.


Thanks,
Sudipto

    

[openstack-dev] [Solum] Proposal to change weekly IRC meeting time

[Devdatta Kulkarni]

Hi team,  

In today's IRC meeting [1], we discussed about changing our weekly IRC meeting 
time from current 
time of 1700 UTC to 1400 UTC to allow our team members from Germany, India, and 
China to participate regularly.

I have submitted a WIP patch [2] to make this change. Please provide your votes 
(+1/-1) on the review. 
I will remove WIP once majority of our current contributors have voted on it.

Note that we have to change the day of our weekly meeting as our preferred time 
slot of 1400 UTC 
is not available in any channel on Tuesday.

I am thinking that if majority of our team members agree, we can move to this 
new time starting  June 1 meeting.

Thanks, 
Devdatta

[1] 
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2016/solum_team_meeting.2016-05-24-17.00.log.html

[2] https://review.openstack.org/#/c/320762/1
__
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] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

[Devdatta Kulkarni]

Hi,

Reading through the thread I thought of adding following points which   might 
be relevant to this discussion.

1) Related to the point of providing an abstraction for deploying apps to 
different form factors: 
OpenStack Solum is a project which allows deploying of applications starting 
from
their source code. Currently we support following deployment options:
(a) deploying app containers in a setup where nova is configured to use 
nova-docker driver
(b) deploying app containers on a VM with one container per VM configuration
(c) deploying app containers to a COE such as a Docker swarm cluster (currently 
under development)

For (a) and (b) we use parameterized Heat templates. For (c), we currently 
assume that
a COE cluster is already created. Solum has a feature whereby app   
developers can provide
different kinds of parameters with theirapp deployment request.
This feature is used to provide cluster creds with the app deployment request.

The deployment option is controlled by the operator at the time
of Solum deployment. Solum's architecture is such that it is straightforward
to add new deployers. I haven't looked at Ironic so won't be able to comment 
how difficult/easy
it would be to add a Ironic deployer in Solum. As Joshua mentioned, it will be 
interesting
to consider different constraints (density, performance, isolation) when 
choosing the
form factor to deploy app containers. Of course, it will also depend on how 
other
OpenStack services are configured within that particular OpenStack setup.


2) Related to the point of high-level application description:
In Solum, we use a simple yaml format for describing an app to Solum. Example 
of an app file can be found here:
https://github.com/openstack/solum/blob/master/examples/apps/python_app.yaml

We have been planning to work on multi-container/microservice-based apps next, 
and have a spec for that:
https://review.openstack.org/#/c/254729/10/specs/mitaka/micro-service-architecture.rst

Any comments/feedback on the spec is welcome.


Lastly, in case you want to try out Solum, here is a link to setting up a 
development environment:
https://wiki.openstack.org/wiki/Solum/solum-development-setup

and getting started guide:
http://docs.openstack.org/developer/solum/getting_started/

Regards,
Devdatta


From: Joshua Harlow 
Sent: Tuesday, April 12, 2016 2:16 PM
To: Flavio Percoco; OpenStack Development Mailing List (not for usage questions)
Cc: foundat...@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One 
Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Flavio Percoco wrote:
> On 11/04/16 18:05 +, Amrith Kumar wrote:
>> Adrian, thx for your detailed mail.
>>
>>
>>
>> Yes, I was hopeful of a silver bullet and as we’ve discussed before (I
>> think it
>> was Vancouver), there’s likely no silver bullet in this area. After that
>> conversation, and some further experimentation, I found that even if
>> Trove had
>> access to a single Compute API, there were other significant
>> complications
>> further down the road, and I didn’t pursue the project further at the
>> time.
>>
>
> Adrian, Amrith,
>
> I've spent enough time researching on this area during the last month
> and my
> conclusion is pretty much the above. There's no silver bullet in this
> area and
> I'd argue there shouldn't be one. Containers, bare metal and VMs differ
> in such
> a way (feature-wise) that it'd not be good, as far as deploying
> databases goes,
> for there to be one compute API. Containers allow for a different
> deployment
> architecture than VMs and so does bare metal.

Just some thoughts from me, but why focus on the
compute/container/baremetal API at all?

I'd almost like a way that just describes how my app should be
interconnected, what is required to get it going, and the features
and/or scheduling requirements for different parts of those app.

To me it feels like this isn't a compute API or really a heat API but
something else. Maybe it's closer to the docker compose API/template
format or something like it.

Perhaps such a thing needs a new project. I'm not sure, but it does feel
like that as developers we should be able to make such a thing that
still exposes the more advanced functionality of the underlying API so
that it can be used if really needed...

Maybe this is similar to an app-catalog, but that doesn't quite feel
like it's the right thing either so maybe somewhere in between...

IMHO I'd be nice to have a unified story around what this thing is, so
that we as a community can drive (as a single group) toward that, maybe
this is where the product working group can help and we as a developer
community can also try to unify behind...

P.S. name for project should be 'silver' related, ha.

-Josh

__
OpenStack Development Mailing List (not for 

[openstack-dev] [Solum] PTL candidacy

[Devdatta Kulkarni]

Hi,

I would like to submit my candidacy to continue as PTL of Solum for the Newton 
cycle.

In Mitaka we accomplished several things including,
- completion of app and workflow API model
- ability to scale application instances
- ability to deploy pre-built application containers
- made Solum's devstack and vagrant development environments stable
- kept up with upstream in regards to release tools and various plugins
- got new contributors

For Newton cycle, I believe we have following challenges in front of us.
- Code stability
  We need to focus on adding more tests towards improving code stability

- Documentation
  Our getting started guide can be improved considerably so that
  it further lowers the barrier for new contributors to get a working
  Solum environment. We need to improve documentation for sample applications
  which we provide within solum repository.

- Multi-container apps
  We need to enhance Solum to build and deploy multi-container applications 
which may
  follow different kinds of container patterns.

- Deprecating plans and assemblies
  When we started Solum, the abstractions of plans and assemblies provided good
  starting points for modeling applications and their deployments. Over time
  it was felt by the team that these abstractions did not align with
  similar abstractions from other systems, and hence the team developed and 
implemented
  abstractions of 'app' and 'workflow'. Time has come for us to deprecate plans 
and
  assemblies. This will greatly simplify our codebase.

- Horizon plugin
  We have a horizon plugin, but we have not actively maintained it in last
  few cycles. Now that the new API is in place,
  it is time for us to revisit the plugin and get it working again.

- Migrate off of oslo incubator
  Currently we are lagging behind in adoption of oslo libraries. In the current
  cycle we got help from several members of the Oslo team towards migrating 
some parts
  of our codebase to use oslo libraries. I am really grateful to them for this 
help.
  I plan to engage with their team more on this in this cycle.

Let us work together on achieving these goals in this cycle.

Best regards,
Devdatta Kulkarni


__
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

[openstack-dev] [Solum] Nominating Vijendar Komalla for Solum core

[Devdatta Kulkarni]

Hi team,

I would like to propose Vijendar Komalla for our core team. Vijendar has been 
actively
contributing to Solum for several months now submitting patches, providing 
great reviews,
and participating actively in our IRC meetings and on Solum IRC channel.
You can find Vijendar's contributions at [1][2].

Please respond with your votes.

Regards,
Devdatta

[1] http://stackalytics.com/?module=solum_id=vijendar-komalla
[2] http://stackalytics.com/?module=python-solumclient_id=vijendar-komalla
__
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] [magnum] Nesting /containers resource under /bays

[Devdatta Kulkarni]

Hi,

I agree with this view point.

Let me provide Solum team's perspective on this.

Solum currently uses Heat to deploy application docker containers that it 
creates.
We have been looking at Magnum as an alternative deployment mechanism.

The fact that Magnum is supporting containers endpoint is very appealing to us.
This is going to allow us to rely on Magnum for all our container management 
and orchestration needs.
Also, we can continue to rely on Heat as it looks like Magnum plugin for Heat
supports container management, in addition to coe management [1].
Without support for managing containers, projects like Solum won't be able to 
leverage Heat
for container orchestration, but will have to use other container orchestration 
systems [2]. This is fine, but if Magnum has that support, we will surely use 
it.

Regards,
Devdatta

[1] 
https://specs.openstack.org/openstack/heat-specs/specs/liberty/magnum-resources.html

[2] 
https://review.openstack.org/#/c/254729/10/specs/mitaka/micro-service-architecture.rst


From: Hongbin Lu 
Sent: Tuesday, January 19, 2016 4:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource  under   
/bays

I don't see why the existent of /containers endpoint blocks your workflow. 
However, with /containers gone, the alternate workflows are blocked.

As a counterexample, some users want to manage containers through an OpenStack 
API for various reasons (i.e. single integration point, lack of domain 
knowledge of COEs, orchestration with other OpenStack resources: VMs, networks, 
volumes, etc.):

* Deployment of a cluster
* Management of that cluster
* Creation of a container
* Management of that container

As another counterexample, some users just want a container:

* Creation of a container
* Management of that container

Then, should we remove the /bays endpoint as well? Mangum is currently in an 
early stage, so workflows are diverse, non-static, and hypothetical. It is a 
risk to have Magnum overfit into a specific workflow by removing others.

For your analogies, Cinder is a block storage service so it doesn't abstract 
the filesystems. Mangum is a container service [1] so it is reasonable to 
abstract containers. Again, if your logic is applied, should Nova have an 
endpoint that let you work with individual hypervisor? Probably not, because 
Nova is a Compute service.

[1] https://github.com/openstack/magnum/blob/master/specs/containers-service.rst

Best regards,
Hongbin

-Original Message-
From: Kyle Kelley [mailto:kyle.kel...@rackspace.com]
Sent: January-19-16 2:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

With /containers gone, what Magnum offers is a workflow for consuming container 
orchestration engines:

* Deployment of a cluster
* Management of that cluster
* Key handling (creation, upload, revocation, etc.)

The first two are handled underneath by Nova + Heat, the last is in the purview 
of Barbican. That doesn't matter though.

What users care about is getting access to these resources without having to 
write their own heat template, create a backing key store, etc. They'd like to 
get started immediately with container technologies that are proven.

If you're looking for analogies Hongbin, this would be more like saying that 
Cinder shouldn't have an endpoint that let you work with individual files on a 
volume. It would be unreasonable to try to abstract across filesystems in a 
meaningful and sustainable way.


From: Hongbin Lu 
Sent: Tuesday, January 19, 2016 9:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Assume your logic is applied. Should Nova remove the endpoint of managing VMs? 
Should Cinder remove the endpoint of managing volumes?

I think the best way to deal with the heterogeneity is to introduce a common 
abstraction layer, not to decouple from it. The real critical functionality 
Magnum could offer to OpenStack is to provide a Container-as-a-Service. If 
Magnum is a Deployment-as-a-service, it will be less useful and won't bring too 
much value to the OpenStack ecosystem.

Best regards,
Hongbin

-Original Message-
From: Clark, Robert Graham [mailto:robert.cl...@hpe.com]
Sent: January-19-16 5:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

+1

Doing this, and doing this well, provides critical functionality to OpenStack 
while keeping said functionality reasonably decoupled from the COE API vagaries 
that would inevitably encumber a solution that sought to provide ‘one api to 
control them all’.

-Rob

From: 

[openstack-dev] [Solum] No meeting on December 29, 2015

[Devdatta Kulkarni]

Hi team,

We will not be holding our weekly IRC meeting on December 29 due to holidays.
We will convene again on January 5.

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

[openstack-dev] [Solum] Hack day / Bug triage day

[Devdatta Kulkarni]

Hi Solum team,

In last two IRC meetings we have discussed about spending a day triaging Solum 
bugs.
In today's meeting, participants agreed to do this on November 18, 2015.
You can find today's meeting logs here:
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2015/solum_team_meeting.2015-11-10-17.00.log.html

This is a virtual event.

We will spend a day exercising Solum. We will triage bugs, try out new cli and 
api functionality, 
push outstanding patches forward, discuss design and implementation of new 
features.

I have setup an etherpad with relevant details.
https://etherpad.openstack.org/p/solum-hackday-nov18-2015

Please add yourself to the etherpad if you plan on participating in the event.

This will also be a good opportunity for anyone interested in Solum to try it 
out.
We can get you started with your Solum development environment.

Thanks,
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

[openstack-dev] [Solum] No meeting on October 27, 2015

[Devdatta Kulkarni]

Hi team,

In this week's IRC meeting we decided to cancel next week's meeting (on October 
27, 2015)
due to Tokyo summit. We will convene again on November 3.

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] Proposal to change weekly IRC meeting time

[Devdatta Kulkarni]

Hi team,

Last week I had sent out an email proposing changes to our weekly IRC meeting 
time
(see below for reference). There was no objection to this proposal.

The patch that makes this change official is now merged.
https://review.openstack.org/#/c/228441/

Starting tomorrow (October 6), our weekly IRC meeting will be held at 1700 UTC
in openstack-meeting-3 channel.

I will update project wiki to reflect this change.

Regards,
Devdatta


From: Devdatta Kulkarni <devdatta.kulka...@rackspace.com>
Sent: Monday, September 28, 2015 8:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Solum] Proposal to change weekly IRC meeting time

Hi team,

In last week's IRC meeting [1], we discussed about changing our weekly IRC
meeting time from current time of 2100 UTC to 1700 UTC to,
(a) avoid conflict with the cross-project meeting, and (b) accommodate 
participants from India/Asia.

I have submitted a WIP review [2] to make this change. Please provide your 
votes (+1/-1) on the review.
I will remove WIP once majority of our contributors have voted on it.
Note that we have to change the meeting channel as our current channel 
(openstack-meeting-alt) is not available at 1700 UTC on Tuesdays.

I am thinking that if majority of our team members agree, we can move to this
new time starting October 6 meeting.

Thanks,
Devdatta

[1] 
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2015/solum_team_meeting.2015-09-22-21.00.log.html

[2] https://review.openstack.org/#/c/228441/
__
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

__
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] [magnum]swarm + compose = k8s?

[Devdatta Kulkarni]

+1 Hongbin.

From perspective of Solum, which hopes to use Magnum for its application 
container scheduling
requirements, deep integration of COEs with OpenStack services like Keystone 
will be useful.
Specifically, I am thinking that it will be good if Solum can depend on 
Keystone tokens to deploy 
and schedule containers on the Bay nodes instead of having to use COE specific 
credentials. 
That way, container resources will become first class components that can be 
monitored 
using Ceilometer, access controlled using Keystone, and managed from within 
Horizon.

Regards,
Devdatta


From: Hongbin Lu 
Sent: Wednesday, September 30, 2015 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
  

+1 from me as well.
 
I think what makes Magnum appealing is the promise to provide 
container-as-a-service. I see coe deployment as a helper to achieve the 
promise, instead of  the main goal.
 
Best regards,
Hongbin
 

From: Jay Lau [mailto:jay.lau@gmail.com]
Sent: September-29-15 10:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
  


+1 to Egor, I think that the final goal of Magnum is container as a service but 
not coe deployment as a service. ;-)

Especially we are also working on Magnum UI, the Magnum UI should export some 
interfaces to enable end user can create container applications but not only 
coe deployment.
 
I hope that the Magnum can be treated as another "Nova" which is focusing on 
container service. I know it is difficult to unify all of the concepts in 
different coe (k8s has pod, service, rc, swarm only has container, nova only 
has VM,  PM with different hypervisors), but this deserve some deep dive and 
thinking to see how can move forward. 
 


 

On Wed, Sep 30, 2015 at 1:11 AM, Egor Guz  wrote:
definitely ;), but the are some thoughts to Tom’s email.

I agree that we shouldn't reinvent apis, but I don’t think Magnum should only 
focus at deployment (I feel we will become another Puppet/Chef/Ansible module 
if we do it ):)
I belive our goal should be seamlessly integrate Kub/Mesos/Swarm to OpenStack 
ecosystem (Neutron/Cinder/Barbican/etc) even if we need to step in to 
Kub/Mesos/Swarm communities for that.

—
Egor

From: Adrian Otto >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, September 29, 2015 at 08:44
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?

This is definitely a topic we should cover in Tokyo.

On Sep 29, 2015, at 8:28 AM, Daneyon Hansen (danehans) 
> wrote:


+1

From: Tom Cammann >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Tuesday, September 29, 2015 at 2:22 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?

This has been my thinking in the last couple of months to completely deprecate 
the COE specific APIs such as pod/service/rc and container.

As we now support Mesos, Kubernetes and Docker Swarm its going to be very 
difficult and probably a wasted effort trying to consolidate their separate 
APIs under a single Magnum API.

I'm starting to see Magnum as COEDaaS - Container Orchestration Engine 
Deployment as a Service.

On 29/09/15 06:30, Ton Ngo wrote:
Would it make sense to ask the opposite of Wanghua's question: should 
pod/service/rc be deprecated if the user can easily get to the k8s api?
Even if we want to orchestrate these in a Heat template, the corresponding heat 
resources can just interface with k8s instead of Magnum.
Ton Ngo,

Egor Guz ---09/28/2015 10:20:02 PM---Also I belive docker compose 
is just command line tool which doesn’t have any api or scheduling feat

From: Egor Guz 
To: 
"openstack-dev@lists.openstack.org" 

Date: 09/28/2015 10:20 PM
Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?




Also I belive docker compose is just command line tool which doesn’t have any 
api or scheduling features.
But during last Docker Conf hackathon PayPal folks implemented docker compose 
executor for Mesos 

[openstack-dev] [Solum] Proposal to change weekly IRC meeting time

[Devdatta Kulkarni]

Hi team,

In last week's IRC meeting [1], we discussed about changing our weekly IRC 
meeting time from current time of 2100 UTC to 1700 UTC to, 
(a) avoid conflict with the cross-project meeting, and (b) accommodate 
participants from India/Asia.

I have submitted a WIP review [2] to make this change. Please provide your 
votes (+1/-1) on the review.
I will remove WIP once majority of our contributors have voted on it.
Note that we have to change the meeting channel as our current channel 
(openstack-meeting-alt) is not available at 1700 UTC on Tuesdays.

I am thinking that if majority of our team members agree, we can move to this 
new time starting October 6 meeting.

Thanks,
Devdatta

[1] 
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2015/solum_team_meeting.2015-09-22-21.00.log.html

[2] https://review.openstack.org/#/c/228441/
__
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] [Glance][Solum] Using os-auth-token and os-image-url with glance client

[Devdatta Kulkarni]

Steve,


Similar to other OpenStack services, Solum client uses the provided/configured 
username and password of a user to get a token, and sends it to Solum API 
service in a http header. On the API side, we use keystonemiddleware to 
validate the token. Upon successful authentication, we store information which 
we get back from keystone (project-id, username, and token) and use it to 
instantiate other services' python clients to interact with them (glance, 
swift, neutron, heat).


Let us know if there is a better approach for enabling inter-service 
interactions.


Thanks,

Devdatta



From: Steve Martinelli <steve...@ca.ibm.com>
Sent: Thursday, September 24, 2015 9:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][Solum] Using os-auth-token and 
os-image-url with glance client


I can't speak to the glance client changes, but this seems like an awkward 
design.

If you don't know the end user's name and password, then how are you getting 
the token? Is it the admin token? Why not create a service account and use 
keystonemiddleware?

Thanks,

Steve Martinelli
OpenStack Keystone Core

[Inactive hide details for Devdatta Kulkarni ---2015/09/24 06:44:57 PM---Hi, 
Glance team, In Solum, we use Glance to store Docke]Devdatta Kulkarni 
---2015/09/24 06:44:57 PM---Hi, Glance team, In Solum, we use Glance to store 
Docker images that we create for applications. We

From: Devdatta Kulkarni <devdatta.kulka...@rackspace.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: 2015/09/24 06:44 PM
Subject: [openstack-dev] [Glance][Solum] Using os-auth-token and os-image-url 
with glance client





Hi, Glance team,

In Solum, we use Glance to store Docker images that we create for applications. 
We use Glance client internally to upload these images. Till recently, 'glance 
image-create' with only token has been
working for us (in devstack). Today, I started noticing that glance 
image-create with just token is not working anymore. It is also not working 
when os-auth-token and os-image-url are passed in. According to documentation 
(http://docs.openstack.org/developer/python-glanceclient/), passing token and 
image-url should work. The client, which I have installed from master, is 
asking username (and password, if username is specified).

Solum does not have access to end-user's password. So we need the ability to 
interact with Glance without providing password, as it has been working till 
recently.

I investigated the issue a bit and have filed a bug with my findings.
https://bugs.launchpad.net/python-glanceclient/+bug/1499540

Can someone help with resolving this issue.

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



__
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] [Glance][Solum] Using os-auth-token and os-image-url with glance client

[Devdatta Kulkarni]

Nikhil, Flavio,

Thank you for giving immediate attention to this issue.

Regards,
Devdatta


From: Flavio Percoco <fla...@redhat.com>
Sent: Friday, September 25, 2015 4:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance][Solum] Using os-auth-token and 
os-image-url with glance client

On 24/09/15 22:44 +, Devdatta Kulkarni wrote:
>Hi, Glance team,
>
>
>In Solum, we use Glance to store Docker images that we create for applications.
>We use Glance client internally to upload these images. Till recently, 'glance
>image-create' with only token has been
>
>working for us (in devstack). Today, I started noticing that glance
>image-create with just token is not working anymore. It is also not working
>when os-auth-token and os-image-url are passed in. According to documentation (
>http://docs.openstack.org/developer/python-glanceclient/), passing token and
>image-url should work. The client, which I have installed from master, is
>asking username (and password, if username is specified).
>
>
>Solum does not have access to end-user's password. So we need the ability to
>interact with Glance without providing password, as it has been working till
>recently.
>
>
>I investigated the issue a bit and have filed a bug with my findings.
>
>https://bugs.launchpad.net/python-glanceclient/+bug/1499540
>
>
>Can someone help with resolving this issue.
>

This should fix your issue and we'll backport it to Liberty.

https://review.openstack.org/#/c/227723/

Thanks for reporting,
Flavio


--
@flaper87
Flavio Percoco

__
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

[openstack-dev] [Glance][Solum] Using os-auth-token and os-image-url with glance client

[Devdatta Kulkarni]

Hi, Glance team,


In Solum, we use Glance to store Docker images that we create for applications. 
We use Glance client internally to upload these images. Till recently, 'glance 
image-create' with only token has been

working for us (in devstack). Today, I started noticing that glance 
image-create with just token is not working anymore. It is also not working 
when os-auth-token and os-image-url are passed in. According to documentation 
(http://docs.openstack.org/developer/python-glanceclient/), passing token and 
image-url should work. The client, which I have installed from master, is 
asking username (and password, if username is specified).


Solum does not have access to end-user's password. So we need the ability to 
interact with Glance without providing password, as it has been working till 
recently.


I investigated the issue a bit and have filed a bug with my findings.

https://bugs.launchpad.net/python-glanceclient/+bug/1499540


Can someone help with resolving this issue.


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

[openstack-dev] [Solum] PTL Candidacy

[Devdatta Kulkarni]

Hi,

I would like to announce my candidacy for the PTL position of Solum for Mitaka.

In my view the challenges in front of us are twofold, which I have outlined 
below.
I believe that I will be able to help us take concrete steps towards addressing 
these

challenges in this cycle.

Our first challenge is to continue developing and evolving Solum's feature set
so that the project becomes a valuable option for operators to offer it in 
their OpenStack installations.

Particularly, in my opinion, following features need to be completed in this 
regard:


(a) Consistency between API and CLI:
Currently Solum API and CLI have slightly different abstractions preventing
consistency of usage when using CLI vs. directly using the REST API.
We have started working on changing this[1], which needs to be completed.

(b) Ability to scale application instances:
For this, we need to investigate how we can use Magnum for satisfying
Solum's application-instance scaling and scheduling requirements.

(c) Insight into application building and deployment process:
This includes, collecting fine-grained logs in various Solum services,
ability to correlate logs across Solum services, collecting and maintaining 
historical information

about user actions to build and deploy applications on Solum.

(d) Ability to build and deploy multi-tier applications:
One idea here is to investigate if something like Magnum's Pod abstraction
can be leveraged for this.

As PTL, I will work towards helping the team move the story forward on these 
features.
Also, whenever required, I will work closely with other OpenStack projects, 
particularly Magnum,
to ensure that our team's requirements are adequately represented in their 
forum.


The second challenge for us is to increase community involvement in and around 
Solum.
Some ideas that I have in this regard are as follows:

(1) Bug squash days:
My involvement with OpenStack started three years ago when I participated
in a bug squash day organized by Anne Gentle at Rackspace Austin[2].
I believe we could organize similar bug squash days for Solum to attract 
new contributors.

Also, there could be experienced Solum contributors whose current 
priorities might
not be allowing them to participate in Solum development, but who might 
still like to

continue contributing to Solum. Bug squash days would provide them a 
dedicated time

and place to participate again in Solum development.

(2) Increasing project visibility:
Some of the actionable items here are:
- Periodic emails to openstack-dev mailing list giving updates on project's 
status, achievements, etc.
- Periodic blog posts
- Presentations at meetup events

(3) Growing community:
- Reaching out to folks who are interested in application build and 
deployment story on OpenStack,
  and inviting them to join Solum IRC meetings and mailing list discussions.
- Reviving mid-cycle meetups

As PTL, I will take actions on some of the above ideas towards helping build 
and grow our community.

About my background -- I have been involved with Solum since the beginning of 
the project.
In this period, I have contributed to the project in several ways including,
designing and implementing different features, fixing bugs, performing code 
reviews,
helping debug gate issues, helping maintain a working Vagrant environment,
maintaining community engagement through various avenues (IRC channel, IRC 
meetings, emails), and so on.
More details about my participation and involvement in the project can be found 
here:
http://stackalytics.com/?module=solum
http://stackalytics.com/?module=python-solumclient

I hope you will give me an opportunity to serve as Solum's PTL for Mitaka.

Best regards,
Devdatta Kulkarni

[1] 
https://github.com/openstack/solum-specs/blob/master/specs/liberty/app-resource.rst
[2] http://www.meetup.com/OpenStack-Austin/events/48406252/

__
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

[openstack-dev] [Solum] Implementing app and workflow resources

[Devdatta Kulkarni]

Hey Solum team,


Recently we had accepted a spec to add new API resources to Solum [1].

Thanks to Ed Cranford, the 'app' resource is  already implemented.

I am working on implementing the workflow resource.

I have created a spec [2] outlining the approach taken for adding the workflow 
resource

and connecting it to the Solum engine (worker and deployer).

If interested, please take a look at the spec and the patches listed there.

I have also listed steps to try out the new resources in Vagrant environment.


Feedback is welcome.


Regards,

Devdatta


[1] 
https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst


[2] https://review.openstack.org/215832
__
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

[openstack-dev] [Solum][Mistral] Help with merging a patch to python-mistralclient

[Devdatta Kulkarni]

Hi, Mistral team,


With recent introduction of programmatic annotations in requirements [1],

projects need to upgrade their version of pbr to work nicely with such 
annotations.

Solum's devstack gate is currently failing [2] because the version of pbr in 
python-mistralclient is

incompatible with what is required to support programmatic annotations.


Robert Collins (a.k.a. lifeless) was kind enough to help us diagnose this issue 
[3] and has submitted a patch to

fix requirements in the python-mistralclient [4].


We would really appreciate it if you can help getting this patch merged.


Thanks,

- Devdatta


[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067823.html

[2] 
http://logs.openstack.org/17/194817/3/check/gate-solum-devstack-dsvm/9f1fcae/logs/devstacklog.txt.gz#_2015-06-24_21_53_50_499

[3] https://botbot.me/freenode/solum/2015-06-24/?msg=42806318page=2

[4] https://review.openstack.org/#/c/195346/
__
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] [api] [all] To changes-since or not to changes-since

[Devdatta Kulkarni]

From: Chris Dent chd...@redhat.com
Sent: Friday, June 19, 2015 4:07 AM
To: OpenStack-dev@lists.openstack.org
Subject: [openstack-dev] [api] [all] To changes-since or not to changes-since

There's an open question in the API-WG on whether to formalize or
otherwise enshrine the concept of a changes-since query parameter
on collection oriented resources across the projects. The original
source of this concept is from Nova's API:

 
http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html

There are arguments for and against but we've been unable to reach a
consensus so the agreed next step was to bring the issue to the
mailing list so more people can hash it out and provide their input.
The hope is that concerns or constraints that those in the group
are not aware of will be revealed and a better decision will be
reached.

The basic idea of changes-since is that it can be used as a way to
signal that the requestor is doing some polling and would like to
ask Give me stuff that has changed since the last time I checked.
As I understand it, for the current implementations (in Nova and
Glance) this means including stuff that has been deleted. Repeated
requests to the resource with a changes-since parameter gives a
running report on the evolving state of the resource. This is intended
to allow efficient polling[0].

The pro camp on this likes it because this is very useful and quite
humane: The requestor doesn't need to know the details of how the
query is is implemented under the hood. That is, if there are
several timestamps associated with the singular resources in the
collection which of those are used for time comparison and which
attributes (such as state with a value of deleted) are used to
determine if a singular resource is included. The service gets to
decide these things and in order for efficient polling to actually
be achieved it needs to do in order to make effective queries of the
data store.

The con camp doesn't like it because it introduces magic, ambiguity
and inconsistency into the API (when viewed from a cross-project
perspective) and one of the defining goals of the working group is
to slowly guide things to some measure of consistency. The
alternate approach is to formulate a fairly rigorous query system
for both filtering[1] and sorting[2] and use that to specify
explicit queries that state I want resources that are newer than time
X in timestamp attribute 'updated_at' _and_ have attribute 'state'
that is one of 'foo', 'bar' or 'baz'.


 I am wondering what are the reasons that changes-since seems
to introduce magic, ambiguity and inconsistency into the API?
Could this be addressed by requiring each service to precisely define
what resources would be returned in response to the changes-since query?
If each service defines this contract then there should not be any
ambiguity on what resources to expect in the response of the query.

That said, we may need to precisely define semantics of what it means
to correctly implement this feature. For instance, could we define
that the set of resources once returned by a particular timestamp
in the query would be guaranteed to remain same for subsequent
executions of the query (idempotency argument)? This may be difficult
to ensure in systems that may be built around providing eventual guarantees.

- 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][app-catalog] [ Supporting swift downloads for operator languagepacks

[Devdatta Kulkarni]

Kevin,


You are right. To avoid overloading the app catalog servers, Solum operators 
can (should?) have local

copies of the languagepacks (LPs) in their Glance/Swift installations which are 
part of their Solum install.


Solum currently does have the ability to download LPs from Glance or Swift and 
use them to build

application containers. Solum internally maintains metadata about each LP. One 
of attributes in this

is to identify whether an LP is an operator LP. The LPs that an operator 
downloads from the app catalog

would be marked as operator LPs in Solum. Also, I would assume that operators 
would define a process to

periodically refresh these LPs from the app catalog.


Currently operator LPs are available for all the tenants in Solum.

Such LPs are downloaded only the first time on the hosts that build application 
containers,

when an application that depends on that LP is built for the very first time.

After that the LP is cached on the host. So the Docker daemon on that host does 
not need to download it again.

Solum also provides configurable option to delete LPs to control hosts' disk 
usage.


We have not yet solved how to enable a tenant to make public the LPs that they 
create

(i.e. make their LPs available to other tenants). The solution for this would 
be different for different backends.

I believe that Glance has a way to make images public. So we could use that for 
Glance.


- Devdatta



From: Fox, Kevin M kevin@pnnl.gov
Sent: Wednesday, June 17, 2015 8:28 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads 
for operator languagepacks

That would work, but would be a per tenant thing? So if you had lots of tenants 
using the same image, it would redownloaded lots of times. Are there any plans 
for glance integration so the cloud deployer could cache it in the image 
catalog? I seem to remember a version of docker that could use glance directly?

Thanks,
Kevin


From: Adrian Otto
Sent: Wednesday, June 17, 2015 5:31:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads 
for operator languagepacks

Kevin,

Magnum has a plan for dealing with that. Solum will likely have a Magnum 
integration that will leverage it:

https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master

With that said, yes, you could also optimize the performance of the upstream by 
caching it locally in swift. You’d want an async proceed to keep it continually 
updated though.

Adrian

 On Jun 17, 2015, at 4:30 PM, Fox, Kevin M kevin@pnnl.gov wrote:

 so, to not beat up on the public facing server, the user would have to copy 
 the container from the public server to the cloud's swift stoage, then the 
 docker hosts could pull from there?

 Thanks,
 Kevin
 
 From: Adrian Otto [adrian.o...@rackspace.com]
 Sent: Wednesday, June 17, 2015 4:21 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift 
 downloads for operator languagepacks

 Kevin,

 On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote:

 Would then each docker host try and redownload the the prebuilt container 
 externally? If you build from source, does it build it once and then all the 
 docker hosts use that one local copy? Maybe Solum needs a mechanism to pull 
 in a prebuilt LP?

 On each docker server Solum downloads built LP’s from swift before the 
 containers are created, so Docker has no reason to contact the public image 
 repository for fetching the LP images because is has a local copy.

 Adrian


 Thanks,
 Kevin
 
 From: Murali Allada [murali.all...@rackspace.com]
 Sent: Wednesday, June 17, 2015 12:53 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift 
 downloads for operator languagepacks

 Kevin\Keith,

 Yes, we would like to use the catalog for globally available artifacts, such 
 as operator languagepacks. More specifically the catalog would be a great 
 place to store metadata about publicly available artifacts to make them 
 searchable and easy to discover.

 The catalog would point to the 'built' artifact, not the 'unbuilt' 
 dockerfile in github.
 The point of languagepacks is to reduce the amount of time the solum CI 
 pipeline
 spends building the users application container. We shouldn't build the 
 languagepack from scratch each time.

 -Murali







 
 From: Keith Bray keith.b...@rackspace.com
 Sent: Wednesday, June 17, 2015 2:10 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Solum][app-catalog] [ 

[openstack-dev] [api][Solum] Request for feedback on new API resource

[Devdatta Kulkarni]

Hi, API WG team,


In Solum, recently we have been working on some changes to our REST API.


Basically, we have introduced a new resource ('app'). The spec for this has 
been accepted by Solum cores.

https://github.com/stackforge/solum-specs/blob/master/specs/liberty/app-resource.rst


Right now we have a patch for review implementing this spec:

https://review.openstack.org/#/c/185147/


If it is not too much to request, I was wondering if someone from your team can 
take a look

at the spec and the review, to see if we are not violating any of your 
guidelines.


Thank you for your help.


- 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

[openstack-dev] [Solum] Update on current status

[Devdatta Kulkarni]

Hi team,


With the recent application from our team to  be included in the big tent

(https://review.openstack.org/190949), I wanted to give a quick update on the 
state of our project.


Before I do that, here is a quick overview of the current capabilities of Solum 
and a very high-level

view of its inner workings.


All along, one of our goals has been to make it possible for application 
developers to easily deploy their

applications to OpenStack. Essentially, provide the ability to go from source 
code to running instance(s)

of an application on OpenStack without having to be greatly familiar with 
OpenStack services that

may be involved in deploying their applications.


In last two cycles we have made considerable progress towards that goal.

From application developer point of view, it is now possible to deploy their 
applications,

starting from the source code, to OpenStack clouds using Solum.

At a high-level, this is achieved in three steps:


1) Build a languagepack (LP)

2) Register the application by providing information about the source 
repository, languagepack to use, and so on

3) Deploy the application


A screencast demonstrating these steps is available on the following link:

https://wiki.openstack.org/wiki/Solum/solum_kilo_demo


Application deployment in Solum happens as follows.


Solum needs a languagepack to build an application.

A languagepack is essentially a Docker container with the specified libraries 
installed on it.

Starting from the specified languagepack, Solum builds an application-specific 
Docker container

(called DU) by adding application's source code to it (DU = LP + application 
source code).

Solum then persists this DU to configured storage backend. We currently support 
Swift, Glance,

and Docker registry. Solum then calls Heat to deploy the DU. Depending on the 
configured storage

backend, the deployment steps differ slightly. For instance, if the configured 
storage is Swift, we use

tempURLs with Heat user-data to run the DU on a VM, whereas if the backend is 
Glance we

use the DU's Glance imageId directly within the Heat template.

Languagepacks can be pre-installed by the operator in their Solum installation, 
or application

developers can create and register new languagepacks per their applications' 
needs.

Apart from building and deploying an application, Solum supports running of 
application-specific tests.

Solum also integrates with external services (currently github) and supports 
webhooks to trigger application deployments. It is also possible to consume 
services, such as databases, via the parameter injection feature.


So that is where we currently stand.


Several other features are still remaining:

- Non-destructive application updates (application updates without changing the 
application URL).

- Scale up/scale down of application DUs.

- Service add/on framework

- Support for environments (Dev, Test, Staging)


Here is a roadmap with these and other suggested features for Liberty:

https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap


Please feel free to add to that list, or reply here with features that you are 
interested in seeing in Solum.

As a reminder, our weekly IRC meeting is on Tuesdays at 2100 UTC in 
openstack-meeting-alt.

Hope to see you there.


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

[openstack-dev] [Solum][Mistral] Help with a patch

[Devdatta Kulkarni]

Hi Mistral team,


Solum's devstack gate is running into an issue probably due to the change

in location of mistral's repositories.


Here is the bug:

https://bugs.launchpad.net/mistral/+bug/1466149


There is a patch which tries to fix the issue:

https://review.openstack.org/#/c/192754/1


If we can get your help with reviewing it and moving it forward, it would be 
greatly appreciated.


Thanks,

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] Why do app names have to be unique?

[Devdatta Kulkarni]

Hi Adrian,


The new app resource that is being implemented 
(https://review.openstack.org/#/c/185147/)
does not enforce name uniqueness.


This issue was discussed here sometime back.
Earlier thread: 
http://lists.openstack.org/pipermail/openstack-dev/2015-March/058858.html


The main argument for requiring unique app names within a tenant was usability. 
In customer research

it was found that users were more comfortable with using names than UUIDs. 
Without the unique app name constraint, users would have to resort to using 
UUIDs when they create multiple apps with the same name.


As a way to accommodate both requirements -- unique names when desired, and 
making them optional when

its not an issue -- we had said that we could make app uniqueness per tenant 
configurable.

So I would be okay if we open a new blueprint to track this work.


Thanks,

- Devdatta



From: Adrian Otto adrian.o...@rackspace.com
Sent: Friday, June 12, 2015 6:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Solum] Why do app names have to be unique?

Team,

While triaging this bug, I got to thinking about unique names:

https://bugs.launchpad.net/solum/+bug/1434293

Should our app names be unique? Why? Should I open a blueprint for a new 
feature to make name uniqueness optional, and default it to on. If not, why?

Thanks,

Adrian
__
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] Should logs be deleted when we delete an app?

[Devdatta Kulkarni]

Yes, the log deletion should be optional.

The question is what should be the default behavior. Should the default be to 
delete the logs and provide a flag to keep them, or keep the logs by default 
and provide a override flag to delete them?

Delete-by-default is consistent with the view that when an app is deleted, all 
its artifacts are deleted (the app's meta data, the deployment units (DUs), and 
the logs). This behavior is also useful in our current state when the app 
resource and the CLI are in flux. For now, without a way to specify a flag, 
either to delete the logs or to keep them, delete-by-default behavior helps us 
clean all the log files from the application's cloud files container when an 
app is deleted.

This is very useful for our CI jobs. Without this, we end up with lots of log 
files in the application's container,

and have to resort to separate scripts to delete them up after an app is 
deleted.


Once the app resource and CLI stabilize it should be straightforward to change 
the default behavior if required.


- Devdatta



From: Adrian Otto adrian.o...@rackspace.com
Sent: Friday, June 12, 2015 6:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Solum] Should logs be deleted when we delete an app?

Team,

We currently delete logs for an app when we delete the app[1].

https://bugs.launchpad.net/solum/+bug/1463986

Perhaps there should be an optional setting at the tenant level that determines 
whether your logs are deleted or not by default (set to off initially), and an 
optional parameter to our DELETE calls that allows for the opposite action from 
the default to be specified if the user wants to override it at the time of the 
deletion. Thoughts?

Thanks,

Adrian
__
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] OpenStack Design Summit Solum sessions

[Devdatta Kulkarni]

Hi Mark,

As Adrian mentioned in another email on this chain,
hopefully we can have a session for the next summit.

In the meantime, you can check out current capabilities of Solum here:
https://solum.readthedocs.org/en/latest/getting_started/index.html

We also have a vagrant environment where you can try out Solum.
A screencast of some of the key current features and details on getting the 
vagrant environment up are
available here:
https://wiki.openstack.org/wiki/Solum/solum_kilo_demo

If you have specific questions/comments, feel free to reach out to us here or 
on #solum on freenode.

Regards,
Devdatta


From: Mark Carlson m...@carlson.net
Sent: Wednesday, May 20, 2015 10:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum] OpenStack Design Summit Solum sessions

Sad but true. Are you here in Vancouver?

Did you see Adrian give his demos on stage yesterday?

He seems to have gone off into Container-Land now

-- mark

On 5/20/15 8:48 AM, Gilbert Pilz wrote:
 Looking at the Design Summit schedule and list of Etherpads it appears that 
 there are no sessions scheduled for Solum. Is this correct?

 ~ gp
 __
 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


__
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

__
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] [Magnum][Heat][Solum] Expression of Bay Status

[Devdatta Kulkarni]

Hey Magnum team,

Just thought of sharing here that in Solum we have a similar requirement. We 
want to know when a Heat stack corresponding to an 'app' is ready so that we 
can mark that app as ready in Solum's database. 
We periodically query Heat to get this information (so essentially a 
polling-based approach).
So far it has been working fine for us.

Also, thanks for sharing insights on issues that may arise when using 
SoftwareDeployments.

Thanks,
- Devdatta


From: Adrian Otto adrian.o...@rackspace.com
Sent: Wednesday, March 11, 2015 7:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum][Heat] Expression of Bay Status

In summary, we have decided to use the usage notification events emitted by 
heat (http://tinyurl.com/oultjm5). This should allow us to detect stack action 
completions, and errors (with reasons) which should be enough for a Bay 
implementation that does not need to poll. Stack timeouts can be passed to heat 
as parameters. This is not as elegant as what Angus and Zane suggested because 
it requires Magnum to access all RPC messages. With their proposed approach we 
could use a Zaqar queue that only emits the stack events relevant to that 
user/tenant. This conforms better to the principle of least privilege. Our 
preference for the decided approach is that it allows us tight integration with 
Heat using functionality that exists today. We admit that this implementation 
will be harder to debug than other options.

More remarks in-line.

On Mar 11, 2015, at 2:27 AM, Jay Lau jay.lau@gmail.com wrote:



 2015-03-10 23:21 GMT+08:00 Hongbin Lu hongbin...@gmail.com:
 Hi Adrian,

 On Mon, Mar 9, 2015 at 6:53 PM, Adrian Otto adrian.o...@rackspace.com wrote:
 Magnum Team,

 In the following review, we have the start of a discussion about how to 
 tackle bay status:

 https://review.openstack.org/159546

 I think a key issue here is that we are not subscribing to an event feed from 
 Heat to tell us about each state transition, so we have a low degree of 
 confidence that our state will match the actual state of the stack in 
 real-time. At best, we have an eventually consistent state for Bay following 
 a bay creation.

 Here are some options for us to consider to solve this:

 1) Propose enhancements to Heat (or learn about existing features) to emit a 
 set of notifications upon state changes to stack resources so the state can 
 be mirrored in the Bay resource.

 A drawback of this option is that it increases the difficulty of 
 trouble-shooting. In my experience of using Heat (SoftwareDeployments in 
 particular), Ironic and Trove, one of the most frequent errors I encountered 
 is that the provisioning resources stayed in deploying state (never went to 
 completed). The reason is that they were waiting a callback signal from the 
 provisioning resource to indicate its completion, but the callback signal was 
 blocked due to various reasons (e.g. incorrect firewall rules, incorrect 
 configs, etc.). Troubling-shooting such problem is generally harder.
 I think that the heat convergence is working on the issues for your 
 concern: https://wiki.openstack.org/wiki/Heat/Blueprints/Convergence

Yes, that wold address part of the concern, but not all of it. Depending on the 
implementation of state exchange, and the configuration of the network, it may 
be possible to create an installation of the system that does not function at 
all due to network ACLs, and almost no clue to the implementer about why it 
does not work. To mitigate this concern, we would want an implementation that 
does not require a bi-directional network trust relationship between Heat and 
Magnum. Instead, implement it in a way that connections are only made from 
Magnum to Heat, so if the stack creation call succeeds, so can the status 
updates. Perhaps we can revisit this design discussion in a future iteration of 
our Bay status code.

Adrian


 2) Spawn a task to poll the Heat stack resource for state changes, and 
 express them in the Bay status, and allow that task to exit once the stack 
 reaches its terminal (completed) state.

 3) Don’t store any state in the Bay object, and simply query the heat stack 
 for status as needed.

 Are each of these options viable? Are there other options to consider? What 
 are the pro/con arguments for each?

 Thanks,

 Adrian



 __
 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


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 

[openstack-dev] [Solum] Should app names be unique?

[Devdatta Kulkarni]

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] Addition to solum core

[Devdatta Kulkarni]

+1


From: James Y. Li [yuel...@gmail.com]
Sent: Saturday, December 27, 2014 9:03 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Solum] Addition to solum core


+1!

-James Li

On Dec 27, 2014 2:02 AM, Adrian Otto 
adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote:
Solum cores,

I propose the following addition to the solum-core group[1]:

+ Ed Cranford (ed--cranford)

Please reply to this email to indicate your votes.

Thanks,

Adrian Otto

[1] https://review.openstack.org/#/admin/groups/229,members Current Members

___
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

Re: [openstack-dev] [Solum] Contributing to Solum

[Devdatta Kulkarni]

Hi Keyvan,

Great to hear that your team is interested in contributing to Solum.

While there is no 'Ideas' page, there is this:
https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap

The team is currently working on the Juno-3 milestone.
In coming weeks we will be discussing the next milestone.

If you get a chance, please join us today in the team meeting.
It will be at 10.00am CDT in #openstack-meeting-alt channel on
chat.freenode.net.

At other times you can find us in the
solum irc channel (#solum on chat.freenode.net) as well.

Cheers,
Devdatta


From: Keyvan Mir Mohammad Sadeghi [keyvan.m.sade...@gmail.com]
Sent: Tuesday, November 18, 2014 4:51 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

[Devdatta Kulkarni]

+1


From: Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com]
Sent: Tuesday, September 30, 2014 12:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum] Core Reviewer Change

+1

On Tue, Sep 30, 2014 at 10:03 AM, Adrian Otto 
adrian.o...@rackspace.commailto: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.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.comhttp://www.mirantis.com/
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Get rid of the sample config file

[Devdatta Kulkarni]

Hi,

We have faced this situation in Solum several times. And in fact this was one 
of the topics
that we discussed in our last irc meeting.

We landed on separating the sample check from pep8 gate into a non-voting gate.
One reason to keep the sample check is so that when say a feature in your code 
fails
due to some upstream changes and for which you don't have coverage in your 
functional tests then
a non-voting but failing sample check gate can be used as a starting point of 
the failure investigation.

More details about the discussion can be found here:
http://eavesdrop.openstack.org/meetings/solum_team_meeting/2014/solum_team_meeting.2014-09-23-16.00.log.txt

- Devdatta


From: David Shrewsbury [shrewsbury.d...@gmail.com]
Sent: Thursday, September 25, 2014 12:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic] Get rid of the sample config file

Hi!

On Thu, Sep 25, 2014 at 12:23 PM, Lucas Alvares Gomes 
lucasago...@gmail.commailto:lucasago...@gmail.com wrote:
Hi,

Today we have hit the problem of having an outdated sample
configuration file again[1]. The problem of the sample generation is
that it picks up configuration from other projects/libs
(keystoneclient in that case) and this break the Ironic gate without
us doing anything.

So, what you guys think about removing the test that compares the
configuration files and makes it no longer gate[2]?

We already have a tox command to generate the sample configuration
file[3], so folks that needs it can generate it locally.

Does anyone disagree?


+1 to this, but I think we should document how to generate the sample config
in our documentation (install guide?).

-Dave
--
David Shrewsbury (Shrews)
___
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

[Devdatta Kulkarni]

Hi Angus, Julien,

No major disagreements.

My thinking is that we should provide more application developer focused
mechanism for customizing workflows (point #3). This may not necessarily be an 
entirely new DSL.
It could just be additions to the current Plan structure. For example, we could 
add a section that
defines what stages we want a particular assembly to go through (unit testing, 
functional testing vs. just unit testing).
These stages could actually be just the task names from a predefined Mistral 
workbook.
Btw, the stages could be listed in a different file (so not tied with a Plan).

I guess the main point is, requiring application developers to define a 
complete workflow
consisting of, what is the entry point, what should happen on failure, how many 
times a task should
be re-tried on failure, etc. seem too low level for application developers to 
be describing while deploying their apps to Solum.
Shouldn't application developers be more concerned with 'what' not 'how'?

- Devdatta


From: Julien Vey [vey.jul...@gmail.com]
Sent: Wednesday, June 04, 2014 10:58 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [solum] reviews for the new API

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
2ZKRDYBubQr1MJKvSV5I3jjOe4lxXXFylbWpYpoU8Y5ZXEKp69R4wrcVISF1jQQ=
=P0Sl
-END PGP SIGNATURE-

___
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

Re: [openstack-dev] [solum] use of the plan for m1

[devdatta kulkarni]

I support this approach. 

Customization of build and deploy lifecycle actions depends on
the ability to register different kinds of services for performing
these actions. I can imagine that operators would want to provide
such services as part of their Solum install. Then, app developers
would be able to find about such services and refer to them in
their application descriptor (may be a plan file, may be
something else). However, for m1, I agree that we should go with
the view that build and deploy services are not externalized, but are
available as default services in Solum.

About the proposed simpler descriptor -- the only question I have is about
the language-pack to use to build the app. Won't we need it in the
application descriptor? So I propose:

artifacts:
- name: My Python App
   artifact_type: application.heroku
   content: { href: http://github.com/some/project }
   language-pack: language-pack-id

- Devdatta


-Original Message-
From: Angus Salkeld angus.salk...@rackspace.com
Sent: Tuesday, March 4, 2014 8:52pm
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [solum] use of the plan for m1

Hi all

I just wanted to clarify our use of the camp plan file (esp. for m1).

Up until now I have been under the impression that use the plan
to describe the app lifecycle (build/test/deploy) and the contents
of the app.

After attempting to write code that converts plans like this into
heat templates started to think that this is not a good idea as
it is mixing two ideas from very different areas. It also makes
the resulting plan complex.

I suggest we move from some of the plans suggested here:
https://etherpad.openstack.org/p/solum-demystified

to a very simple:
artifacts:
- name: My Python App
   artifact_type: application.heroku
   content: { href: http://github.com/some/project }

For m1 we can assume a lifecycle of build and deploy. After that
we can figure out how we would want to expose the lifecycle
choices/customization to the user.

Thoughts?

-Angus

___
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] Question about solum-minimal-cli BP

[devdatta kulkarni]

Hi Shaunak,

-Original Message-
From: Shaunak Kashyap shaunak.kash...@rackspace.com
Sent: Monday, February 17, 2014 3:47pm
To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject: [openstack-dev] [solum] Question about solum-minimal-cli BP

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hey folks,

I was reading through 
https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation
 and have a question.

If I’m understanding “app create” and “assembly create” correctly, the user 
will have to run “app create” first, followed by “assembly create” to have a 
running application. Is this correct? 

 Yes.

If so, what is the reason for “app create” not automatically creating one 
assembly as well?

 One of the reasons 'app create' and 'assembly create' are distinct actions is
to decouple creation of assemblies from creation/registration of a plan (which 
is represented by app create).
This allows supporting creation of multiple assemblies from the same registered 
plan.


Thanks,

Shaunak



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Solum] Question about Zuul's role in Solum

[devdatta kulkarni]

Hi,

I have been looking at Zuul for last few days and had a question
about its intended role within Solum.

From what I understand, Zuul is a code gating system.

I have been wondering if code gating is something we are considering as a 
feature
to be provided in Solum? If yes, then Zuul is a perfect fit.
But if not, then we should discuss what benefits do we gain by using Zuul
as an integral part of Solum.

It feels to me that right now we are treating Zuul as a conduit for triggering 
job(s)
that would do the following:
- clone/download source
- run tests
- create a deployment unit (DU) if tests pass
- upload DU to glance
- trigger the DU deployment workflow

In the language-pack working group we have talked about being able to do
CI on the submitted code and building the DUs only after tests pass. 
Now, there is a distinction between doing CI on merged code vs.
doing it before code is permanently merged to master/stable branches.
The latter is what a 'code gating' system does, and Zuul is a perfect fit for 
this.
For the former though, using a code gating system is not be needed.
We can achieve the former with an API endpoint, a queue,
and a mechanism to trigger job(s) that perform above mentioned steps.

I guess it comes down to Solum's vision. If the vision includes supporting, 
among other things, code gating
to ensure that Solum-managed code is never broken, then Zuul is a perfect fit.
Of course, in that situation we would want to ensure that the gating 
functionality is pluggable
so that operators can have a choice of whether to use Zuul or something else.
But if the vision is to be that part of an overall application lifecycle 
management flow which deals with
creation and scaling of DUs/plans/assemblies but not necessarily be a code 
gate, then we should re-evaluate Zuul's role
as an integral part of Solum.

Thoughts?

Thanks,
Devdatta



___
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

[devdatta kulkarni]

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-dev@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

Re: [openstack-dev] [Solum] Lang-pack working group meeting cancelled today due to freenode DOS, will be rescheduled

[devdatta kulkarni]

Sounds good to me.

- Devdatta

-Original Message-
From: Clayton Coleman ccole...@redhat.com
Sent: Monday, February 3, 2014 12:10pm
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Solum] Lang-pack working group meeting cancelled 
today due to freenode DOS, will be rescheduled

Good point.  We can try immediately after the git inter workflow if folks 
prefer.  12pm US CST, 1pm EST.

- Original Message -
 Which time zone?
 
 On Wednesdays between 11.00am - noon (US Central time) there is git
 integration working group meeting.
 
 
 -Original Message-
 From: Clayton Coleman ccole...@redhat.com
 Sent: Monday, February 3, 2014 10:35am
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Solum] Lang-pack working group meeting cancelled
 today due to freenode DOS, will be rescheduled
 
 Maybe wednesday at noon?
 
 ___
 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Lang-pack working group meeting cancelled today due to freenode DOS, will be rescheduled

[devdatta kulkarni]

Which time zone?

On Wednesdays between 11.00am - noon (US Central time) there is git integration 
working group meeting.


-Original Message-
From: Clayton Coleman ccole...@redhat.com
Sent: Monday, February 3, 2014 10:35am
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Solum] Lang-pack working group meeting cancelled 
today due to freenode DOS, will be rescheduled

Maybe wednesday at noon?

___
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] Deployment units and plans

[devdatta kulkarni]

Hi,

In this week's language pack working group meeting we briefly touched
upon questions regarding creation of deployment units, their handling
with respect to plans, etc.

I have created a etherpad page where I have put these and other questions.

https://etherpad.openstack.org/p/RegardingLangPacks

Please feel free to add more questions and/or answers.

Thanks,
Devdatta



-Original Message-
From: Krishna Raman kra...@gmail.com
Sent: Wednesday, January 29, 2014 1:00am
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Solum][Git] Meeting reminder  agenda

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,

We have a git working group meeting scheduled for tomorrow morning at 9am PST.
Please follow link for additional timezones:
http://www.worldtimebuddy.com/?qm=1lid=100,8,524901,2158177h=100date=2014-01-29sln=17-18

I currently have only 3 things on the agenda:
- solum_hacks branch work:
- test cases
- code organization
- patch submission process
- integration point with Solum API
- integration point with Solum Plan file
- integration with LP

Please let me know if you would like additional items added to the agenda.

Thanks
—Krishna


___
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

[devdatta kulkarni]

+1


-Original Message-
From: Murali Allada murali.all...@rackspace.com
Sent: Sunday, January 26, 2014 8:19pm
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Cc: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Solum] Proposed changes to solum-core

+1 



 On Jan 25, 2014, at 9:04 AM, Roshan Agrawal roshan.agra...@rackspace.com 
 wrote:
 
 +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

___
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] Using Zuul in the Git-pull blueprint

[devdatta kulkarni]

-Original Message-
From: Krishna Raman kra...@gmail.com
Sent: Friday, December 13, 2013 9:44am
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

On Dec 12, 2013, at 1:39 PM, devdatta kulkarni 
devdatta.kulka...@rackspace.com wrote:

 We followed on the Zuul question in this week's git-integration working group 
 meeting.
 
 mordred has created an etherpad with a high-level description of Zuul and how 
 it might
 fit with Solum't git integration workflow
 
 https://etherpad.openstack.org/p/ZuulSolum
 
 The working group seemed to be coming to the consensus that we want to use a 
 single workflow
 engine, as far as possible, for all of Solum's workflow needs.
 This brought up the question about, what are really Solum's workflow 
 requirements. 

Hi

I had a long conversation with Monty yesterday and we flushed out a few things 
I would like to run by the group.
I have also included answers to the questions below.

 
 At a high-level, I think that Solum has three different kinds of workflows.
 
 1) Workflow around getting user code into Solum
   - This is the git integration piece being worked out in the git-integration
 working group.

This is possible using the Zuul workflows. Would potentially require a little 
work in Zuul.

 
 2) Workflow around creating language pack(s).
   - The main workflow requirement here involves ability to run tests before 
 creating a language pack.
 There was some discussion in language-pack working group about this 
 requirement.

This is also possible using Zuul and in-fact would benefit Solum by providing 
config file based build workflows
that could be customized by ops personelle. For e.g.. one DU might require SVN, 
another might require git 
and a jenkins CI based unit test before triggering Langpack, other DUs might 
wish to leverage gerrit etc.
This would be possible through Zuul without having to reinvent it on the other 
workflow engine.

 
 3) Workflow around deploying created language pack(s) in order to instantiate 
 an assembly.
   - The deployment may potentially contain several steps, some of which may 
 be long running, such as
   populating a database. Further, there may be a need to checkpoint 
 intermediate steps
   and retry the workflow from the failed point.

This is probably not a very good fit for Zuul. It can handle simple workflow 
but won’t be able to do the
complex checkpointing, rollback, retry logic etc.

 
 
 mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and 
 pull-by-solum)
 We want to know if #2 and #3 can also be achieved by Zuul.
 If not, we want to know what are the available options.
 
 mordred, thanks for the etherpad; looking forward to the digram :)


Zuul is workflow engine capable of running simple workflows. It is probably not 
suitable for all of Solum but would
manage the source - DU flow quite nicely. Initially my thoughts were that I 
wanted to avoid having 2 workflow
engines in Solum but there is another way to look at it…

During out F2F, we had said that we should have a Solum API where we could just 
post DU images. This would
allow someone to build the DU outside Solum and just provide it. We could use 
this same API as a clean interface to
separated out the DU build flow from the DU deploy flow. Once this is done, the 
DU build flow (#1, #2 above)
could be cleanly handled by Zuul and the DU deploy flow by whatever complex 
engine the rest of Solum would
use.

 I think this makes sense.

If I were to tie this discussion back to the various working groups and 
blueprints, I think
the git-integration and language-pack working groups are targeting the DU 
build flow (#1 and #2).
On the other hand, the work being done as part of 'specify-lang-pack' blueprint 
and 'pluggable-template-generation'
are targeting parts of #3. There would be additional blueprints for other 
aspects of #3.

- Devdatta


This approach has a few advantages:
* Re-uses what Openstack already uses but its build  CI process (and 
potentially makes it better)
* Allows operations who deploy Solum to customize their build process 
without having to change Solum
* Allows us to leverage the Zuul/OpenStack-infra team to help us solve 
the DU build flow instead of having 
  to go alone

—Krishna

 
 
 thanks,
 devkulkarni
 
 
 -Original Message-
 From: Roshan Agrawal roshan.agra...@rackspace.com
 Sent: Monday, December 9, 2013 10:57am
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
 
 
 -Original Message-
 From: Krishna Raman [mailto:kra...@gmail.com]
 Sent: Sunday, December 08, 2013 11:24 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

[devdatta kulkarni]

We followed on the Zuul question in this week's git-integration working group 
meeting.

mordred has created an etherpad with a high-level description of Zuul and how 
it might
fit with Solum't git integration workflow

https://etherpad.openstack.org/p/ZuulSolum

The working group seemed to be coming to the consensus that we want to use a 
single workflow
engine, as far as possible, for all of Solum's workflow needs.
This brought up the question about, what are really Solum's workflow 
requirements. 

At a high-level, I think that Solum has three different kinds of workflows.

1) Workflow around getting user code into Solum
   - This is the git integration piece being worked out in the git-integration
 working group.

2) Workflow around creating language pack(s).
   - The main workflow requirement here involves ability to run tests before 
creating a language pack.
 There was some discussion in language-pack working group about this 
requirement.

3) Workflow around deploying created language pack(s) in order to instantiate 
an assembly.
   - The deployment may potentially contain several steps, some of which may be 
long running, such as
   populating a database. Further, there may be a need to checkpoint 
intermediate steps
   and retry the workflow from the failed point.


mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and 
pull-by-solum)
We want to know if #2 and #3 can also be achieved by Zuul.
If not, we want to know what are the available options.

mordred, thanks for the etherpad; looking forward to the digram :)


thanks,
devkulkarni


-Original Message-
From: Roshan Agrawal roshan.agra...@rackspace.com
Sent: Monday, December 9, 2013 10:57am
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint


 -Original Message-
 From: Krishna Raman [mailto:kra...@gmail.com]
 Sent: Sunday, December 08, 2013 11:24 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
 
 Hi all,
 
 We had a very good meeting last week around the git-pull blueprint. During
 the discussion, Monty suggested using Zuul to manage the git repository
 access and workflow.
 While he is working on sending the group a diagram and description of what
 he has in mind, I had a couple of other questions which I am hoping the
 extended group will be able to answer.
 
 1) Zuul is currently an infrastructure project.
   - Is there anything that prevents us from using it in Solum?
   - Does it need to be moved to a normal OpenStack project?
 
 2) Zuul provides a sort of workflow engine. This workflow engine could
 potentially be used to initiate and manage: API Post - git flow - lang pack
 flow.
   - Have there been any discussion after the F2F where we have
 discussed using some other workflow engine?

There hasn't been further discussion since F2F.
Most of the processes in Solum will really be customizable workflows, and use 
of a generic workflow engine is definitely worth discussing. We may still use 
to leverage Zuul for the gerrit/git/checkin piece, but Solum will have workflow 
needs beyond that. 

   - Is Zuul's engine generic enough to be used in Solum? (Hoping
 Monty can help with this one)
   - Perhaps only use it to manage the API post - git flow
 stages?
 
 Thanks
 -Krishna
 ___
 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] [Plan]

[devdatta kulkarni]

Hi Adrian,

Thanks for creating https://etherpad.openstack.org/p/solum-demystified

I am really excited to see the examples. Especially cool is how
examples 2 and 3 demonstrate using a component (solum_glance_id) created
as part of example 1.


Some questions/comments:

1) Summarizing the sequence of events just to make sure I understand them 
correctly: 
   a) User selects a language pack and specifies its id in the plan file
   b) User creates repo with the plan file in it.

   After this the flow could be:
   c.1) User uses solum cli to 'create' an application by giving reference to 
  the repo uri
   c.1.1) Solum creates a plan resource
   c.1.2) Solum model interpreter creates a Heat stack and does the rest of 
the
things needed to create a assembly. 
   (The created plan resource does not play any part in assembly creation 
as such.
Its only role is being a 'trackback' to track the plan from which the 
assembly was created.)

   or, 
   c.2) User uses solum cli to 'create/register' a plan by providing reference 
to the repo uri. 
c.2.1) Solum creates the plan resource.
   c.2) User uses solum cli to 'create' an application by specifying the 
created plan
resource uri
(In this flow, the plan is actively used).
  

2) Addition of new solum specific attributes in a plan specification is 
interesting.
   I imagine those can be contributed back as Solum profile to CAMP spec?


3) Model interpreter for generating Heat stack from a plan is a nice idea.
   For all: Are there any recommended libraries for this?


4) Just to confirm, I assume that the api-spec-review etherpad 
(https://etherpad.openstack.org/p/solum-api-spec-review), 
   is for fyi purpose only. If someone wants to know what is the current 
thinking about API, they should
   just look at the solum-demystified etherpad 
(https://etherpad.openstack.org/p/solum-demystified)


Thanks,
Devdatta



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

[devdatta kulkarni]

There are several different points being raised here,
all very interesting. Trying to separate them below.

1) Using objects as an abstraction for versioned data:
   This seems like a good direction overall, especially from the point-of-view
   of backwards compatibility of consumers of the object. However, after 
looking through some
   of the objects defined in nova/objects/, I am not sure if I understand how
   this works. Specifically, it is not clear to me how might the consumer of 
the 
   object be able to query different versions of it at runtime.


2) Using objects as an abstraction to support different kinds of backends
   (SQL and non-SQL backends):
   - Again, a good direction overall. From implementation point-of-view though
   this may become tricky, in the sense that the object layer would need to be
   designed with just the right amount of logic so as to be able to work with 
either 
   a SQL or a non-SQL backend. It will be good to see some examples of how this 
might 
   be done if there are any existing examples somewhere.


3) From Solum's point-of-view, the concern around the potential downtime
   that may be incurred in the API-layer because of breaking object model 
changes,
   and so, investigating how to design this correctly right from the start.
   - This is a valid concern. We will have to design for this at sometime or 
other anyways.
   Doing this first up might be good with regards to understanding how the 
decision of
   using versioned objects would tie with the API layer implemented in 
Pecan+WSME.
   I don't have much experience with either, so would love to hear about it 
from those who do.


Best Regards,
Devdatta


-Original Message-
From: Clayton Coleman ccole...@redhat.com
Sent: Thursday, November 7, 2013 8:26pm
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Cc: Dan Smith d...@danplanet.com
Subject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration

- Original Message -

  https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420

  https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43
 
 This API and these models are what we are trying to avoid exposing to
 the rest of nova. By wrapping these in our NovaObject-based structures,
 we can bundle versioned data and methods together which is what we need
 for cross-version compatibility and parity for the parts of nova that
 are not allowed to talk to the database directly.
 
 See the code in nova/objects/* for the implementations. Right now, these
 just call into the db_api.py, but eventually we want to move the actual
 database implementation into the objects themselves and hopefully
 dispense with most or all of the sqlalchemy/* stuff. This also provides
 us the ability to use other persistence backends that aren't supported
 by sqlalchemy, or that don't behave like it does.
 
 If you're going to be at the summit, come to the objects session on
 Thursday where we'll talk about this in more detail. Other projects have
 expressed interest in moving the core framework into Oslo so that we're
 all doing things in roughly the same way. It would be good to get you
 started on the right way early on before you have the migration hassle
 we're currently enjoying in Nova :)
 
 --Dan
 

The summit session was excellent - next step for me is to look through what the 
right abstraction is going to be for objects that keeps the db details properly 
isolated and the API surface on /objects suitably coarse (in line with the long 
discussion in Nova about non-SQL backends, the consensus of which is that the 
domain object model needs to abstract whole interaction flows, vs granular 
steps).  I'll try to have some example code to debate after I get back from 
summit.

Even assuming Solum has a fairly small persistence model, in the long run I 
believe it's fair to say that the ability to perform live upgrades will become 
critical for all operators.  One of the side effects of supporting potentially 
millions of applications (at the high end, and not an unreasonable estimate for 
hosted environments) is that any period of downtime at the API level will 
prevent users from making deployments, which is a direct line-of-business 
concern.  Designing around live upgrades - specifically, the requirement that 
code must be aware of two versions of a schema at the same time - implies that 
the domain model must be able to be aware of those versions on an object basis. 
 For reference, [1] and [2] contain some of the Nova discussion, and Nova in 
icehouse is going to be moving this way.  I'd prefer (it's important to Red 
Hat) to design for that from the beginning and be working towards that end.

Do folks have additional questions or concerns about my exploration of a 
versioned domain object model from day one?  Are there others who would like to 
embrace quick and dirty and explicitly ignore this 

Re: [openstack-dev] [Solum] Separation of concerns for 0.1 git deploy blueprint

[devdatta kulkarni]

Hi Clayton,

Thank you for creating these diagrams. They are a great starting point for 
discussions
around the git deploy blueprint.

Some questions/comments:

In both the diagrams, what do the arrows indicate? 
Data flow, control-flow, or some kind of ordering relationship?
Especially, the arrow from 'respond to client' to 'HEAT' box in the top diagram
is a bit confusing. Correct me if I am wrong, but my guess is that the meaning
of that arrow is, 'stack create' will happen after responding to client has 
happened.
Although, this may not be necessarily true (both those steps can happen in 
async manner).

Second, how do you envision tying together the two diagrams/high-level flows?
Specifically, once we have a built artifact (second diagram), how do we go 
about deploying it?

We could either have, build abstraction - REST API - deploy abstraction,
or, build abstraction - deploy abstraction. What are your thoughts on this?

Best regards,
Devdatta


-Original Message-
From: Adrian Otto adrian.o...@rackspace.com
Sent: Wednesday, October 30, 2013 8:01pm
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Solum] Separation of concerns for 0.1 git deploy 
blueprint

Clayton,

Thanks for adding the diagram illustrating the flow. I expect that respond to 
client may not be a synchronous flow, rather that if creation of a repo takes 
a while that the API may return a 202 Accepted, and the client can poll a 
status attribute to determine completion and learn the actual location of the 
repo created. So in that case respond to client also might mean update async 
status. This will be particularly important in cases where an external SCM 
system is used (perhaps Github).

I agree that this will be a helpful reference to guide our upcoming interactive 
design sessions. I have created the first call for participation, which will 
also be separately announced:

https://wiki.openstack.org/wiki/Solum/BreakoutMeetings

Adrian

On Oct 30, 2013, at 2:45 PM, Clayton Coleman ccole...@redhat.com wrote:

 In the IRC meeting yesterday [1] we discussed splitting the individual topics 
 for the git deploy blueprint [2] into rough sub areas.  To help frame the 
 abstractions we've been discussing I roughed out a flow based on two user 
 inputs, REST API create and a git push and then tried to draw boxes around 
 the related bits.  The abstractions roughly correspond to the potential areas 
 that can be the focus of break out discussions (and if they don't a good 
 discussion of why is always helpful).
 
 Squiggly boxes are potential plugin points and/or strong responsibility 
 boundaries.  Feedback desirable.
 
 [1] http://irclogs.solum.io/2013/solum.2013-10-29-16.01.txt
 [2] 
 https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/GitIntegration#Flow_Boundaries
 
 
 
 ___
 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