Re: [openstack-dev] [magnum]swarm + compose = k8s?

[Mike Spreitzer]

> From: 王华 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 09/28/2015 11:34 PM
> Subject: [openstack-dev] [magnum]swarm + compose = k8s?
> 
> Hi folks,
> 
> Magnum now exposes service, pod, etc to users in kubernetes coe, but
> exposes container in swarm coe. As I know, swarm is only a scheduler
> of container, which is like nova in openstack. Docker compose is a 
> orchestration program which is like heat in openstack. k8s is the 
> combination of scheduler and orchestration. So I think it is better 
> to expose the apis in compose to users which are at the same level as 
k8s.
> 

Why should the users be deprived of direct access to the Swarm API when it 
is there?

Note also that Compose addresses more general, and differently focused, 
orchestration than Kubernetes; the latter only offers homogenous scaling 
groups --- which a docker-compose.yaml file can not even describe.

Regards,
Mike



__
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-operators] [cinder] [all] The future of Cinder API v1

[John Griffith]

On Mon, Sep 28, 2015 at 6:19 PM, Mark Voelker  wrote:

> FWIW, the most popular client libraries in the last user survey[1] other
> than OpenStack’s own clients were: libcloud (48 respondents), jClouds (36
> respondents), Fog (34 respondents), php-opencloud (21 respondents),
> DeltaCloud (which has been retired by Apache and hasn’t seen a commit in
> two years, but 17 respondents are still using it), pkgcloud (15
> respondents), and OpenStack.NET (14 respondents).  Of those:
>
> * libcloud appears to support the nova-volume API but not the cinder API:
> https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251
>
> * jClouds appears to support only the v1 API:
> https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds
>
> * Fog also appears to only support the v1 API:
> https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99
>
> * php-opencloud appears to only support the v1 API:
> https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html
>
> * DeltaCloud I honestly haven’t looked at since it’s thoroughly dead, but
> I can’t imagine it supports v2.
>
> * pkgcloud has beta-level support for Cinder but I think it’s v1 (may be
> mistaken): https://github.com/pkgcloud/pkgcloud/#block-storagebeta
> and
> https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage
>
> * OpenStack.NET does appear to support v2:
> http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm
>
> Now, it’s anyone’s guess as to whether or not users of those client
> libraries actually try to use them for volume operations or not
> (anecdotally I know a few clouds I help support are using client libraries
> that only support v1), and some users might well be using more than one
> library or mixing in code they wrote themselves.  But most of the above
> that support cinder do seem to rely on v1.  Some management tools also
> appear to still rely on the v1 API (such as RightScale:
> http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html
> ).  From that perspective it might be useful to keep it around a while
> longer and disable it by default.  Personally I’d probably lean that way,
> especially given that folks here on the ops list are still reporting
> problems too.
>
> That said, v1 has been deprecated since Juno, and the Juno release notes
> said it was going to be removed [2], so there’s a case to be made that
> there’s been plenty of fair warning too I suppose.
>
> [1]
> http://superuser.openstack.org/articles/openstack-application-developers-share-insights
> [2] https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7
>
> At Your Service,
>
> Mark T. Voelker
>
>
>
> > On Sep 28, 2015, at 7:17 PM, Sam Morrison  wrote:
> >
> > Yeah we’re still using v1 as the clients that are packaged with most
> distros don’t support v2 easily.
> >
> > Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our
> “volume” endpoint to point to v2 (we have a volumev2 endpoint too) and the
> client breaks.
> >
> > $ cinder list
> > ERROR: OpenStack Block Storage API version is set to 1 but you are
> accessing a 2 endpoint. Change its value through --os-volume-api-version or
> env[OS_VOLUME_API_VERSION].
> >
> > Sam
> >
> >
> >> On 29 Sep 2015, at 8:34 am, Matt Fischer  wrote:
> >>
> >> Yes, people are probably still using it. Last time I tried to use V2 it
> didn't work because the clients were broken, and then it went back on the
> bottom of my to do list. Is this mess fixed?
> >>
> >>
> http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html
> >>
> >> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny 
> wrote:
> >> Hi all,
> >>
> >> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API
> was introduced in Grizzly and v1 API is deprecated since Juno.
> >>
> >> After [1] is merged, Cinder API v1 is disabled in gates by default.
> We've got a filed bug [2] to remove Cinder v1 API at all.
> >>
> >>
> >> According to Deprecation Policy [3] looks like we are OK to remote it.
> But I would like to ask Cinder API users if any still use API v1.
> >> Should we remove it at all Mitaka release or just disable by default in
> the cinder.conf?
> >>
> >> AFAIR, only Rally doesn't support API v2 now and I'm going to implement
> it asap.
> >>
> >> [1] https://review.openstack.org/194726
> >> [2] https://bugs.launchpad.net/cinder/+bug/1467589
> >> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
> >>
> >> Regards,
> >> Ivan Kolodyazhny
> >>
> >> ___
> >> OpenStack-operators mailing list
> >> openstack-operat...@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >>
> >>
> >> 

[openstack-dev] [magnum]swarm + compose = k8s?

[王华]

Hi folks,

Magnum now exposes service, pod, etc to users in kubernetes coe, but
exposes container in swarm coe. As I know, swarm is only a scheduler of
container, which is like nova in openstack. Docker compose is a
orchestration program which is like heat in openstack. k8s is the
combination of scheduler and orchestration. So I think it is better to
expose the apis in compose to users which are at the same level as k8s.


Regards
Wanghua
__
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] [Cinder] [Manila] Will NFS stay with Cinder as a reference implementation?

[Sheng Bo Hou]

Hi folks,

I have a question about the file services in OpenStack.

As you know there is a generic NFS driver in Cinder and other file system 
drivers inherit it, while the project Manila is determined to provide the 
file system service.

Will NFS stay with Cinder as the reference implementation for the coming 
release or releases? Are all the file system drivers going to move to 
Manila? 
What is relation between Manila as FSaaS and NFS in Cinder?
Any ideas?

Thank you.

Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
__
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?

[Adrian Otto]

Wanghua,

I do follow your logic, but docker-compose only needs the docker API to 
operate. We are intentionally avoiding re-inventing the wheel. Our goal is not 
to replace docker swarm (or other existing systems), but to compliment it/them. 
We want to offer users of Docker the richness of native APIs and supporting 
tools. This way they will not need to compromise features or wait longer for us 
to implement each new feature as it is added. Keep in mind that our pod, 
service, and replication controller resources pre-date this philosophy. If we 
started out with the current approach, those would not exist in Magnum.

Thanks,

Adrian

On Sep 28, 2015, at 8:32 PM, ?? 
> wrote:

Hi folks,

Magnum now exposes service, pod, etc to users in kubernetes coe, but exposes 
container in swarm coe. As I know, swarm is only a scheduler of container, 
which is like nova in openstack. Docker compose is a orchestration program 
which is like heat in openstack. k8s is the combination of scheduler and 
orchestration. So I think it is better to expose the apis in compose to users 
which are at the same level as k8s.


Regards
Wanghua
__
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?

[Ton Ngo]

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,



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 (https://github.com/mohitsoni/compose-executor)
which can give you pod like experience.

―
Egor

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

Wanghua,

I do follow your logic, but docker-compose only needs the docker API to
operate. We are intentionally avoiding re-inventing the wheel. Our goal is
not to replace docker swarm (or other existing systems), but to compliment
it/them. We want to offer users of Docker the richness of native APIs and
supporting tools. This way they will not need to compromise features or
wait longer for us to implement each new feature as it is added. Keep in
mind that our pod, service, and replication controller resources pre-date
this philosophy. If we started out with the current approach, those would
not exist in Magnum.

Thanks,

Adrian

On Sep 28, 2015, at 8:32 PM, 王华 > wrote:

Hi folks,

Magnum now exposes service, pod, etc to users in kubernetes coe, but
exposes container in swarm coe. As I know, swarm is only a scheduler of
container, which is like nova in openstack. Docker compose is a
orchestration program which is like heat in openstack. k8s is the
combination of scheduler and orchestration. So I think it is better to
expose the apis in compose to users which are at the same level as k8s.


Regards
Wanghua
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org<
mailto: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-dev] [election] [tc] TC candidacy -- Let's do this

[Clint Byrum]

Greetings Stackers,

Some of you I know, some of you I'm meeting for the first time.

Through the last 3 years, since I got involved with OpenStack, I've
seen it grow and mature, and I want to make sure it continues to as we
all raise the bar on what we expect from the not so little cloud engine
that could.

I've been involved with some controversial projects, and been pleased
to watch our community handle most of the controversy by simply choosing
to make our developers' actions uncontroversial with the big tent. I aim
to continue this trend of being inclusive and supportive of the efforts
of everyone who wants to throw their hat in as an OpenStack project.

I intend to put users first, and operators second, with our beloved
developers third. I consider myself "all of the above", and I think that
should bring useful perspective to the TC. This isn't an area I think
OpenStack has failed in, but I believe it requires constant vigilance.

I do have a specific agenda for all of OpenStack, and which I will use
my TC seat to advance whenever possible:

- Streamline everything. There are parts of OpenStack that scale to
the moon, and parts that don't. I think OpenStack should try hard for
everything with the OpenStack moniker on it to put performance and
stability above all else.

- Measure efficiency. We don't necessarily measure how efficient OpenStack
is, or how much each change is affecting its efficiency. We have blog
posts, and anecdotes, but I want to have actual graphs that belong to
the community and show us if we're living up to our goals.

- Resiliency. Once we're streaminling things, and measuring our progress,
we should be able to separate performance problems for reliability
problems, and make OpenStack more resilient in general. This serves
users and operators alike, but it may be hard for developers. That's ok,
we like hard stuff, right?

- No sacred cows. I feel like sometimes the tech we have chosen is
either begrudgingly kept because there's nothing good enough to change,
or hallowed as "the way this works." I would like to challenge some of
those cows and see if we can't do a little bit of work toward streamlining
and resilience by challenging conventional wisdom.

I'm going to work on these things from outside the TC anyway. However,
with the added influence that a seat on the TC provides, I can certainly
work on these things even more.

Thank you for your time!

Clint Byrum
IBM

__
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?

[Egor Guz]

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 (https://github.com/mohitsoni/compose-executor)
which can give you pod like experience.

―
Egor

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

Wanghua,

I do follow your logic, but docker-compose only needs the docker API to 
operate. We are intentionally avoiding re-inventing the wheel. Our goal is not 
to replace docker swarm (or other existing systems), but to compliment it/them. 
We want to offer users of Docker the richness of native APIs and supporting 
tools. This way they will not need to compromise features or wait longer for us 
to implement each new feature as it is added. Keep in mind that our pod, 
service, and replication controller resources pre-date this philosophy. If we 
started out with the current approach, those would not exist in Magnum.

Thanks,

Adrian

On Sep 28, 2015, at 8:32 PM, 王华 
> wrote:

Hi folks,

Magnum now exposes service, pod, etc to users in kubernetes coe, but exposes 
container in swarm coe. As I know, swarm is only a scheduler of container, 
which is like nova in openstack. Docker compose is a orchestration program 
which is like heat in openstack. k8s is the combination of scheduler and 
orchestration. So I think it is better to expose the apis in compose to users 
which are at the same level as k8s.


Regards
Wanghua
__
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] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

[Gilles Dubreuil]

On 15/09/15 19:55, Sofer Athlan-Guyot wrote:
> Gilles Dubreuil  writes:
> 
>> On 15/09/15 06:53, Rich Megginson wrote:
>>> On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote:
 Hi,

 Gilles Dubreuil  writes:

> A. The 'composite namevar' approach:
>
> keystone_tenant {'projectX::domainY': ... }
>   B. The 'meaningless name' approach:
>
>keystone_tenant {'myproject': name='projectX', domain=>'domainY',
> ...}
>
> Notes:
>   - Actually using both combined should work too with the domain
> supposedly overriding the name part of the domain.
>   - Please look at [1] this for some background between the two
> approaches:
>
> The question
> -
> Decide between the two approaches, the one we would like to retain for
> puppet-keystone.
>
> Why it matters?
> ---
> 1. Domain names are mandatory in every user, group or project. Besides
> the backward compatibility period mentioned earlier, where no domain
> means using the default one.
> 2. Long term impact
> 3. Both approaches are not completely equivalent which different
> consequences on the future usage.
 I can't see why they couldn't be equivalent, but I may be missing
 something here.
>>>
>>> I think we could support both.  I don't see it as an either/or situation.
>>>

> 4. Being consistent
> 5. Therefore the community to decide
>
> Pros/Cons
> --
> A.
 I think it's the B: meaningless approach here.

>Pros
>  - Easier names
 That's subjective, creating unique and meaningful name don't look easy
 to me.
>>>
>>> The point is that this allows choice - maybe the user already has some
>>> naming scheme, or wants to use a more "natural" meaningful name - rather
>>> than being forced into a possibly "awkward" naming scheme with "::"
>>>
>>>   keystone_user { 'heat domain admin user':
>>> name => 'admin',
>>> domain => 'HeatDomain',
>>> ...
>>>   }
>>>
>>>   keystone_user_role {'heat domain admin user@::HeatDomain':
>>> roles => ['admin']
>>> ...
>>>   }
>>>

>Cons
>  - Titles have no meaning!
>>>
>>> They have meaning to the user, not necessarily to Puppet.
>>>
>  - Cases where 2 or more resources could exists
>>>
>>> This seems to be the hardest part - I still cannot figure out how to use
>>> "compound" names with Puppet.
>>>
>  - More difficult to debug
>>>
>>> More difficult than it is already? :P
>>>
>  - Titles mismatch when listing the resources (self.instances)
>
> B.
>Pros
>  - Unique titles guaranteed
>  - No ambiguity between resource found and their title
>Cons
>  - More complicated titles
> My vote
> 
> I would love to have the approach A for easier name.
> But I've seen the challenge of maintaining the providers behind the
> curtains and the confusion it creates with name/titles and when not sure
> about the domain we're dealing with.
> Also I believe that supporting self.instances consistently with
> meaningful name is saner.
> Therefore I vote B
 +1 for B.

 My view is that this should be the advertised way, but the other method
 (meaningless) should be there if the user need it.

 So as far as I'm concerned the two idioms should co-exist.  This would
 mimic what is possible with all puppet resources.  For instance you can:

file { '/tmp/foo.bar': ensure => present }

 and you can

file { 'meaningless_id': name => '/tmp/foo.bar', ensure => present }

 The two refer to the same resource.
>>>
>>> Right.
>>>
>>
>> I disagree, using the name for the title is not creating a composite
>> name. The latter requires adding at least another parameter to be part
>> of the title.
>>
>> Also in the case of the file resource, a path/filename is a unique name,
>> which is not the case of an Openstack user which might exist in several
>> domains.
>>
>> I actually added the meaningful name case in:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074325.html
>>
>> But that doesn't work very well because without adding the domain to the
>> name, the following fails:
>>
>> keystone_tenant {'project_1': domain => 'domain_A', ...}
>> keystone_tenant {'project_1': domain => 'domain_B', ...}
>>
>> And adding the domain makes it a de-facto 'composite name'.
> 
> I agree that my example is not similar to what the keystone provider has
> to do.  What I wanted to point out is that user in puppet should be used
> to have this kind of *interface*, one where your put something
> meaningful in the title and one where you put something meaningless.
> The fact that the meaningful one is a compound one shouldn't matter to
> the user.
> 

There is a big blocker of making use of domain 

[openstack-dev] [all] devstack default worker changes

[Sean Dague]

We used to default to using the mysqldb driver in devstack, which is a C
binding that is not eventlet aware. This means that any time a db query
is executed the entire greenlet is blocked. This behavior meant that in
devstack (and in oslo.concurrency) default number of workers for things
like API servers and conductors was = num of cores on the machine so
that everything wouldn't be deadlocked all the time when touching the
database.

The downside is we fixed concurrency with memory, which means you have a
lot of idle python eating all your memory all the time. Devstack in 4GB
isn't really an option any more with more than a small number of
services turned on.

We changed the default mysql driver to the pure python one back early in
Liberty. It shook out some bugs, but things got good quickly on that.
Just recently we decided to see if we could drop the worker count as
well in upstream devstack and gate jobs.

The new math will give you numproc / 4 workers for these services (min
of 2). This seems to be running fine. More interestingly it ends up
keeping an extra 1GB+ of memory in page cache by the end of the gate
runs, which seems to be making things a bit more stable, and under less
load. ( https://review.openstack.org/#/c/226831/ )

We've not seen any down side of this change yet, and it should make it
easier to get devstack into a smaller footprint VM. However, I wanted to
make sure people knew it was a change in case they see some new edge
failure condition that could be related to it.

So, it should mostly all be flowers and unicorns. But, keep an eye out
in case a troll shows up under a bridge somewhere.

-Sean

-- 
Sean Dague
http://dague.net


__
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] [devstack] Is there a way to configure devstack for one flat external network using Kilo, Neutron?

[Christopher Aedo]

On Mon, Sep 28, 2015 at 7:08 AM, Mike Spreitzer  wrote:
> Is there a way to configure devstack to install Neutron such that there is
> just one network and that is an external network and Nova can create Compute
> Instances on it, using projects of Kilo vintage?

Mike, this might help, I have a script to make a local.conf that works
on a single-nic VM with Neutron:
https://github.com/aedocw/devstack-helper

Would just have to add the bits to specify using the Kilo release.  I
would definitely appreciate feedback on this though, especially if the
resulting config isn't quite right.

-Christopher

__
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] [TripleO] tripleo.org theme

[Dan Prince]

On Fri, 2015-09-25 at 12:31 -0500, Ben Nemec wrote:
> On 09/25/2015 07:34 AM, Dan Prince wrote:
> > It has come to my attention that we aren't making great use of our
> > tripleo.org domain. One thing that would be useful would be to have
> > the
> > new tripleo-docs content displayed there. It would also be nice to
> > have
> > quick links to some of our useful resources, perhaps Derek's CI
> > report
> > [1], a custom Reviewday page for TripleO reviews (something like
> > this
> > [2]), and perhaps other links too. I'm thinking these go in the
> > header,
> > and not just on some random TripleO docs page. Or perhaps both
> > places.
> 
> Note that there's a TripleO Inbox Dashboard linked toward the bottom
> of
> https://wiki.openstack.org/wiki/TripleO#Review_team (It should
> probably
> be higher up than that, since it's incredibly useful).  This is
> actually
> what I use for tracking TripleO reviews, and would be a simple thing
> to
> start with for this.
> 
> +1 to everything else.
> 
> > 
> > I was thinking that instead of the normal OpenStack theme however
> > we
> > could go a bit off the beaten path and do our own TripleO theme.
> > Basically a custom tripleosphinx project that we ninja in as a
> > replacement for oslosphinx.
> > 
> > Could get our own mascot... or do something silly with words. I'm
> > reaching out to graphics artists who could help with this sort of
> > thing... but before that decision is made I wanted to ask about
> > thoughts on the matter here first.
> 
> I like the mascot/logo idea. 

Exactly. Mascot's are cool. Lets get one.

>  Not sure why we would want to deviate from
> the standard OpenStack docs theme though.  What is your motivation
> for
> suggesting that?

This isn't about moving away from OpenStack. The only reason I wanted a
custom theme was to:

1) Display the mascot

2) Provide a custom header for our TripleO specific things. For
starters I've got a custom ReviewDay report with all TripleO specific
reviews along with the TripleO CI status report we've found so useful.

Looks something like this ATM:

https://twitter.com/dovetaildan/status/648270765972832256/photo/1

In short think of the tripleo.org theme as a lense into the TripleO
world upstream. It is only meant to guide you back to all of the
upstream OpenStack goodness that already exists.

Dan


> 
> Also, if we get a mascot I want t-shirts. ;-)
> 
> > 
> > Speak up... it would be nice to have this wrapped up before Tokyo.
> > 
> > [1] http://goodsquishy.com/downloads/tripleo-jobs.html
> > [2] http://status.openstack.org/reviews/
> > 
> > Dan
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > 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:unsubs
> cribe
> 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] [Designate] Topics for Design Summit

[Hayes, Graham]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

Just a reminder that this etherpad is still nearly empty :).

https://etherpad.openstack.org/p/designate-design-summit-tokyo

Can we try and get a few more topics so we can talk about it on
Wednesday?

Thanks,

Graham

- -- 
Graham Hayes
Software Engineer
DNS as a Service
Advanced Network Services
HP Helion Cloud - Platform Services

GPG Key: 7D28E972


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWCW/3AAoJEPRBUqpJBgIieFgH/A21CbLyzOCpZhDK3XfsA3S+
xsVdH7GNosItWIaarvgHC2GcckR+OSHHE2XLzeVGaZ4ugdkbp6C99CaczOF1VszZ
pNDcKWAUcnQt+qmwt8AbSbpNw6L0EYRujLjR4ekmfclQlLZ/uqtd59VCN/dArcnH
21j7852lP1PjVN+YwJ74dN/wdqTWCZ6zl+jgdG2DoF+y9ZWOQlNItp2khd8hJBrg
cx+LQESNZsCSwdJrueC25qMJ0Qfm29/jnNoET8r8ly5RMui2Zdv3Jz/QHt527nsD
2InrBdEi/+RXllYufpuFXIJAMMXQ+HtAZrcyOpSSfEiJJ6IHJ8y6yGUFTY2QuwE=
=qTQ6
-END PGP SIGNATURE-

__
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] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[Ben Swartzlander]

I've always thought it was a bit strange to require new drivers to merge 
by milestone 1. I think I understand the motivations of the policy. The 
main motivation was to free up reviewers to review "other things" and 
this policy guarantees that for 75% of the release reviewers don't have 
to review new drivers. The other motivation was to prevent vendors from 
turning up at the last minute with crappy drivers that needed a ton of 
work, by encouraging them to get started earlier, or forcing them to 
wait until the next cycle.


I believe that the deadline actually does more harm than good.

First of all, to those that don't want to spend time on driver reviews, 
there are other solutions to that problem. Some people do want to review 
the drivers, and those who don't can simply ignore them and spend time 
on what they care about. I've heard people who spend time on driver 
reviews say that the milestone-1 deadline doesn't mean they spend less 
time reviewing drivers overall, it just all gets crammed into the 
beginning of each release. It should be obvious that setting a deadline 
doesn't actually affect the amount of reviewer effort, it just 
concentrates that effort.


The argument about crappy code is also a lot weaker now that there are 
CI requirements which force vendors to spend much more time up front and 
clear a much higher quality bar before the driver is even considered for 
merging. Drivers that aren't ready for merge can always be deferred to a 
later release, but it seems weird to defer drivers that are high quality 
just because they're submitted during milestones 2 or 3.


All the the above is just my opinion though, and you shouldn't care 
about my opinions, as I don't do much coding and reviewing in Cinder. 
There is a real reason I'm writing this email...


In Manila we added some major new features during Liberty. All of the 
new features merged in the last week of L-3. It was a nightmare of merge 
conflicts and angry core reviewers, and many contributors worked through 
a holiday weekend to bring the release together. While asking myself how 
we can avoid such a situation in the future, it became clear to me that 
bigger features need to merge earlier -- the earlier the better.


When I look at the release timeline, and ask myself when is the best 
time to merge new major features, and when is the best time to merge new 
drivers, it seems obvious that *features* need to happen early and 
drivers should come *later*. New major features require FAR more review 
time than new drivers, and they require testing, and even after they 
merge they cause merge conflicts that everyone else has to deal with. 
Better that that works happens in milestones 1 and 2 than right before 
feature freeze. New drivers can come in right before feature freeze as 
far as I'm concerned. Drivers don't cause merge conflicts, and drivers 
don't need huge amounts of testing (presumably the CI system ensure some 
level of quality).


It also occurs to me that new features which require driver 
implementation (hello replication!) *really* should go in during the 
first milestone so that drivers have time to implement the feature 
during the same release.


So I'm asking the Cinder core team to reconsider the milestone-1 
deadline for drivers, and to change it to a deadline for new major 
features (in milestone-1 or milestone-2), and to allow drivers to merge 
whenever*. This is the same pitch I'll be making to the Manila core 
team. I've been considering this idea for a few weeks now but I wanted 
to wait until after PTL elections to suggest it here.


-Ben Swartzlander


* I don't actually care if/when there is a driver deadline, what I care 
about is that reviewers are free during M-1 to work on reviewing/testing 
of features. The easiest way to achieve that seems to be moving the 
driver deadline.



__
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] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[Duncan Thomas]

I can definitely see your logic, but we've a history in cinder of vendors
trying to cram drivers in at the last minute which we very much wanted to
stop dead. I might suggest that the second milestone, rather than the first
might be a better one to dedicate to driver reviews...

An interesting thing is that, from the point of view of cinder core, we
don't need more drivers. We've drivers coming out of our ears. Sure it is
incrementally better to get more drivers, but we've got far more to gain
from harnessing the developers of companies who want to merge new drivers
for core work (or ci improvements, or translation or docs improvements or
whatever) than we do from yet another driver. Increasing the bar for enter
slightly does us no major harm that I can tell - there's a clear benefit
from having your driver in tree, so if there's a small 'tax' to get added
then I suspect we can benefit from it substantially.

Definitely worth reviewing deadlines and other bureaucracy occasionally and
working out if it is still serving us well.

Cheers
On 28 Sep 2015 20:32, "Ben Swartzlander"  wrote:

> I've always thought it was a bit strange to require new drivers to merge
> by milestone 1. I think I understand the motivations of the policy. The
> main motivation was to free up reviewers to review "other things" and this
> policy guarantees that for 75% of the release reviewers don't have to
> review new drivers. The other motivation was to prevent vendors from
> turning up at the last minute with crappy drivers that needed a ton of
> work, by encouraging them to get started earlier, or forcing them to wait
> until the next cycle.
>
> I believe that the deadline actually does more harm than good.
>
> First of all, to those that don't want to spend time on driver reviews,
> there are other solutions to that problem. Some people do want to review
> the drivers, and those who don't can simply ignore them and spend time on
> what they care about. I've heard people who spend time on driver reviews
> say that the milestone-1 deadline doesn't mean they spend less time
> reviewing drivers overall, it just all gets crammed into the beginning of
> each release. It should be obvious that setting a deadline doesn't actually
> affect the amount of reviewer effort, it just concentrates that effort.
>
> The argument about crappy code is also a lot weaker now that there are CI
> requirements which force vendors to spend much more time up front and clear
> a much higher quality bar before the driver is even considered for merging.
> Drivers that aren't ready for merge can always be deferred to a later
> release, but it seems weird to defer drivers that are high quality just
> because they're submitted during milestones 2 or 3.
>
> All the the above is just my opinion though, and you shouldn't care about
> my opinions, as I don't do much coding and reviewing in Cinder. There is a
> real reason I'm writing this email...
>
> In Manila we added some major new features during Liberty. All of the new
> features merged in the last week of L-3. It was a nightmare of merge
> conflicts and angry core reviewers, and many contributors worked through a
> holiday weekend to bring the release together. While asking myself how we
> can avoid such a situation in the future, it became clear to me that bigger
> features need to merge earlier -- the earlier the better.
>
> When I look at the release timeline, and ask myself when is the best time
> to merge new major features, and when is the best time to merge new
> drivers, it seems obvious that *features* need to happen early and drivers
> should come *later*. New major features require FAR more review time than
> new drivers, and they require testing, and even after they merge they cause
> merge conflicts that everyone else has to deal with. Better that that works
> happens in milestones 1 and 2 than right before feature freeze. New drivers
> can come in right before feature freeze as far as I'm concerned. Drivers
> don't cause merge conflicts, and drivers don't need huge amounts of testing
> (presumably the CI system ensure some level of quality).
>
> It also occurs to me that new features which require driver implementation
> (hello replication!) *really* should go in during the first milestone so
> that drivers have time to implement the feature during the same release.
>
> So I'm asking the Cinder core team to reconsider the milestone-1 deadline
> for drivers, and to change it to a deadline for new major features (in
> milestone-1 or milestone-2), and to allow drivers to merge whenever*. This
> is the same pitch I'll be making to the Manila core team. I've been
> considering this idea for a few weeks now but I wanted to wait until after
> PTL elections to suggest it here.
>
> -Ben Swartzlander
>
>
> * I don't actually care if/when there is a driver deadline, what I care
> about is that reviewers are free during M-1 to work on reviewing/testing of
> features. The easiest way to 

Re: [openstack-dev] [neutron] congrats to armax!

[Armando M.]

On 25 September 2015 at 17:03, Ryan Moats  wrote:

> First, congratulations to armax on being elected PTL for Mitaka. Looking
> forward to Neutron improving over the next six months.
>
> Second thanks to everybody that voted in the election. Hopefully we had
> something close to 100% turnout, because that is an important
> responsibility of the population.
>

My humble thanks. I'll do my best to serve this community well, and not
disappoint the trust given.

Cheers,
Armando

>
>
> Ryan
>
> __
> 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] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[Sean McGinnis]

On Mon, Sep 28, 2015 at 12:13:04PM -0600, John Griffith wrote:
> On Mon, Sep 28, 2015 at 11:29 AM, Ben Swartzlander 
> wrote:
> 
> > I've always thought it was a bit strange to require new drivers to merge
> > by milestone 1. I think I understand the motivations of the policy. The
> > main motivation was to free up reviewers to review "other things" and this
> > policy guarantees that for 75% of the release reviewers don't have to
> > review new drivers. The other motivation was to prevent vendors from
> > turning up at the last minute with crappy drivers that needed a ton of
> > work, by encouraging them to get started earlier, or forcing them to wait
> > until the next cycle.
> >
> 
> ​Yep, these were some of the ideas behind it but the first milestone did
> for sure create some consequences.​
> 
> 
> >
> > I believe that the deadline actually does more harm than good.
> >
> 
> ​In retrospect I'd agree with you on this.  We ended up spending our major
> focus for the first milestone on nothing but drivers which I think looking
> back wasn't so good.  But to be fair, we try things, see how they work,
> revisit and move on.  Which is the plan last I checked (there's a proposal
> to talk about some of this at the summit in Tokyo).​
> 

We will have more discussion on this for sure, but I figure I should
chime in with some of my thoughts.

I definitely do want to reconsider our deadlines. There are going to
be challenges no matter what point in the cycle we set for things like
driver submissions, but as John said, we need to try things and see how
it works. I saw a lot of logic in moving new drivers to the first
milestone, but I don't think it worked out as well as we had hoped it
would.

The biggest problem I see is it made the drivers a major focus for the
first part of the cycle. It seemed to me that that distracted a lot of
focus from core functionality. It got that part out of the way (mostly)
but it sort of disrupted the momentum from things discussed at the
Summit.

> 
> >
> > First of all, to those that don't want to spend time on driver reviews,
> > there are other solutions to that problem. Some people do want to review
> > the drivers, and those who don't can simply ignore them and spend time on
> > what they care about. I've heard people who spend time on driver reviews
> > say that the milestone-1 deadline doesn't mean they spend less time
> > reviewing drivers overall, it just all gets crammed into the beginning of
> > each release. It should be obvious that setting a deadline doesn't actually
> > affect the amount of reviewer effort, it just concentrates that effort.
> >
> 

I do think this is a very valid point.

I certainly don't have all the answers. I'm looking forward to the
discussions around this to get ideas of how to make things better. But I
do think we need to try something else to find a better way. Maybe we'll
end up back to where we are, but I do think it warrants more discussion.

Sean

__
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] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[Ben Swartzlander]

On 09/28/2015 02:42 PM, Walter A. Boring IV wrote:

On 09/28/2015 10:29 AM, Ben Swartzlander wrote:
I've always thought it was a bit strange to require new drivers to 
merge by milestone 1. I think I understand the motivations of the 
policy. The main motivation was to free up reviewers to review "other 
things" and this policy guarantees that for 75% of the release 
reviewers don't have to review new drivers. The other motivation was 
to prevent vendors from turning up at the last minute with crappy 
drivers that needed a ton of work, by encouraging them to get started 
earlier, or forcing them to wait until the next cycle.


I believe that the deadline actually does more harm than good.
But harm to whom?   It certainly puts the pressure on driver 
developers to make sure they get involved in the Cinder community and 
get aware of when the deadlines are.
I believe it simply shifts the time in which drivers get into tree. My 
$0.02 of opinion is, that if a new driver developer misses the 
milestone, then they have the rest of the release to work on getting 
CI up and running and ready to go for the next release.   I'm not sure 
I see the harm to the Cinder community or the project.   It's a 
deadline that a driver developer has to be aware of and compensate 
for.  We've had how many drivers land in the last 2 releases using 
this requirement?  I believe it's somewhere of 20+ drivers?




Walt I think you missed the point of my suggestion. I don't actually 
care when drivers go in. What I care about is that features land early 
so they can get appropriate review time and testing time, and so that 
merge conflicts can be dealt with. It seems to me that many people 
review nothing but drivers during milestone-1 so I suggest moving the 
deadline so those reviews can happen later. The 3rd milestone is when 
there should be no big architectural changes going on and is IMO the 
safest time to merge drivers. So the harm of the milestone-1 deadline is 
that is sucks all the oxygen out of the room, delaying features to 
milestone-2.


-Ben




First of all, to those that don't want to spend time on driver 
reviews, there are other solutions to that problem. Some people do 
want to review the drivers, and those who don't can simply ignore 
them and spend time on what they care about. I've heard people who 
spend time on driver reviews say that the milestone-1 deadline 
doesn't mean they spend less time reviewing drivers overall, it just 
all gets crammed into the beginning of each release. It should be 
obvious that setting a deadline doesn't actually affect the amount of 
reviewer effort, it just concentrates that effort.


The argument about crappy code is also a lot weaker now that there 
are CI requirements which force vendors to spend much more time up 
front and clear a much higher quality bar before the driver is even 
considered for merging. Drivers that aren't ready for merge can 
always be deferred to a later release, but it seems weird to defer 
drivers that are high quality just because they're submitted during 
milestones 2 or 3.
I disagree here.  CI doesn't prevent you from having a crappy driver.  
Your driver just needs to pass CI tests.  CI ensures that your driver 
works, but doesn't ensure that it
really meats the core reviewers standards for code.  Do we care? I 
think we do.  Having drivers talk directly to the db, or FC drivers 
missing the FCZM decorators for auto zoning, etc.




All the the above is just my opinion though, and you shouldn't care 
about my opinions, as I don't do much coding and reviewing in Cinder. 
There is a real reason I'm writing this email...


In Manila we added some major new features during Liberty. All of the 
new features merged in the last week of L-3. It was a nightmare of 
merge conflicts and angry core reviewers, and many contributors 
worked through a holiday weekend to bring the release together. While 
asking myself how we can avoid such a situation in the future, it 
became clear to me that bigger features need to merge earlier -- the 
earlier the better.


When I look at the release timeline, and ask myself when is the best 
time to merge new major features, and when is the best time to merge 
new drivers, it seems obvious that *features* need to happen early 
and drivers should come *later*. New major features require FAR more 
review time than new drivers, and they require testing, and even 
after they merge they cause merge conflicts that everyone else has to 
deal with. Better that that works happens in milestones 1 and 2 than 
right before feature freeze. New drivers can come in right before 
feature freeze as far as I'm concerned. Drivers don't cause merge 
conflicts, and drivers don't need huge amounts of testing (presumably 
the CI system ensure some level of quality).


It also occurs to me that new features which require driver 
implementation (hello replication!) *really* should go in during the 
first milestone so that drivers have time to 

[openstack-dev] [ironic] [javascript] ironic-webclient seeks more reviewers and contributors

[Michael Krotscheck]

Hey everyone!

The ironic webclient is finally moving forward again, however we're at that
odd stage where most of the ironic team is Awesome Python and Hardware
types, and we're lacking reviewers able to keep an eye on our Angular
Javascript code. In the interest of not creating an echo chamber over here,
we'd like to invite anyone and everyone interested in looking at our JS
code to add their own +2, and maybe even contribute a bit!

https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient,n,z
__
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] [puppet] Moving puppet-ceph to the Openstack big tent

[Richard Raseley]

On 09/28/2015 08:31 AM, David Moreau Simard wrote:
> puppet-ceph currently lives in stackforge [1] which is being retired
> [2]. puppet-ceph is also mirrored on the Ceph Github organization [3].
> This version of the puppet-ceph module was created from scratch and
> not as a fork of the (then) upstream puppet-ceph by Enovance [4].
> Today, the version by Enovance is no longer officially maintained
> since Red Hat has adopted the new release.
>
> Being an Openstack project under Stackforge or Openstack brings a lot
> of benefits but it's not black and white, there are cons too.
>
> It provides us with the tools, the processes and the frameworks to
> review and test each contribution to ensure we ship a module that is
> stable and is held to the highest standards.
> But it also means that:
> - We forego some level of ownership back to the Openstack foundation,
> it's technical committee and the Puppet Openstack PTL.
> - puppet-ceph contributors will also be required to sign the
> Contributors License Agreement and jump through the Gerrit hoops [5]
> which can make contributing to the project harder.
>
> We have put tremendous efforts into creating a quality module and as
> such it was the first puppet module in the stackforge organization to
> implement not only unit tests but also integration tests with third
> party CI.
> Integration testing for other puppet modules are just now starting to
> take shape by using the Openstack CI inrastructure.
>
> In the context of Openstack, RDO already ships with a mean to install
> Ceph with this very module and Fuel will be adopting it soon as well.
> This means the module will benefit from real world experience and
> improvements by the Openstack community and packagers.
> This will help further reinforce that not only Ceph is the best
> unified storage solution for Openstack but that we have means to
> deploy it in the real world easily.
>
> We all know that Ceph is also deployed outside of this context and
> this is why the core reviewers make sure that contributions remain
> generic and usable outside of this use case.
>
> Today, the core members of the project discussed whether or not we
> should move puppet-ceph to the Openstack big tent and we had a
> consensus approving the move.
> We would also like to hear the thoughts of the community on this topic.
>
> Please let us know what you think.
There was some discussion a while back around whether or not to bring
those modules into the project which provide support for
OpenStack-related tools which were not part of OpenStack themselves. The
specific example at that time was the puppet-midonet module.

Unfortunately the consensus was to not allow these modules in. I think
now, as I did then, that there is a lot of value in bringing some of
these things into the project, as so many of our implementations depend
on them. I also understand the other perspective, but think any concerns
could be addressed by building some formal criteria about what third
party tools are 'blessed'.

I look forward to seeing feedback from the rest of the community on this.

Regards,

Richard



signature.asc
Description: OpenPGP digital signature
__
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] [TripleO] tripleo.org theme

[Dan Prince]

On Mon, 2015-09-28 at 09:43 -0400, James Slagle wrote:
> On Fri, Sep 25, 2015 at 8:34 AM, Dan Prince 
> wrote:
> > It has come to my attention that we aren't making great use of our
> > tripleo.org domain. One thing that would be useful would be to have
> > the
> > new tripleo-docs content displayed there. It would also be nice to
> > have
> > quick links to some of our useful resources, perhaps Derek's CI
> > report
> > [1], a custom Reviewday page for TripleO reviews (something like
> > this
> > [2]), and perhaps other links too. I'm thinking these go in the
> > header,
> > and not just on some random TripleO docs page. Or perhaps both
> > places.
> > 
> > I was thinking that instead of the normal OpenStack theme however
> > we
> > could go a bit off the beaten path and do our own TripleO theme.
> > Basically a custom tripleosphinx project that we ninja in as a
> > replacement for oslosphinx.
> 
> Would the content of tripleo-docs be exactly the same as what is
> published at http://docs.openstack.org/developer/tripleo-docs/ ?

Yes. Exactly the same content with just a custom header to link to some
TripleO specific reports that our upstream community finds useful.

> 
> I think it probably should be, and be updated on every merged commit.
> If that's not the case, I think it should be abundantly clear why
> someone might would use one set of docs over the other.

The sample site I have currently refreshes every 7 or so minutes.
Basically you'd get new tripleo-docs content, new reviewday reviews,
and an updated CI report on each refresh.

> 
> I'm not sure about why we'd want a different theme. Is it just so
> that
> it's styled the same as the rest of tripleo.org?

Because mascot's are cool? Because we can? We don't have to have a
custom theme but I'd just as soon have one. I mean oslo has a moose,
Ironic has got a bear, perhaps TripleO needs an owl? Or something :)

This isn't about stepping away from upstream. Just a simple way to
organize upstream resources specific to the TripleO project in a new
fashion. A different way to slice into the project...

Dan

> 
> > 
> > Could get our own mascot... or do something silly with words. I'm
> > reaching out to graphics artists who could help with this sort of
> > thing... but before that decision is made I wanted to ask about
> > thoughts on the matter here first.
> > 
> > Speak up... it would be nice to have this wrapped up before Tokyo.
> > 
> > [1] http://goodsquishy.com/downloads/tripleo-jobs.html
> > [2] http://status.openstack.org/reviews/
> 
> +1 to everything else. I had put what to do with tripleo.org on the
> tokyo etherpad. Someone (not sure who) also suggested:
> 
> * collaborative blogging

Yes. I added this section I think. I think perhaps that is something we
could add later if we choose.

> * serve upstream generated overcloud images?

Sure. This would require a bit more infrastructure but we could use the
domain for this sort of thing too.

> 
> I like both of those ideas as well. For the blogging, maybe we could
> parse the rss feed from planet.openstack.org and pick out the TripleO
> stuff somehow.
> 
> 
> 

__
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] [Congress] hands on lab

[Tim Hinrichs]

Hi Alex,

I went through the HOL.  Some feedback...

1.  When starting up, it paused for a while showing the following
messages.  Maybe that caused the issues I mention below.
Waiting for network configuration...
Waiting up to 60 more seconds for network configuration...

2.  Maybe spell out the first paragraph of "Starting the Devstack VM".
Maybe something like

To run the devstack VM, first install VirtualBox.  Then download the image
from XXX and start the VM.  (From VirtualBox's File menu, Import Appliance
and then choose the file you downloaded.)

Now you'll want to ssh to the VM from your laptop so it's easier to copy
and paste.  (The VM is setup to use bridge networking with DHCP.) To find
the IP address, login to the VM through the console.

username: congress
password: congress

Run ‘ifconfig’ to get the IP address of the VM for eth0

$ ifconfig eth0

Now open a terminal from your laptop and ssh to that IP address using the
same username and password from above.



Now that devstack is running, you can point your laptop's browser to the
VM's IP address you found earlier to use Horizon.

 3. Connection problems.
Horizon.  The browser brought up the login screen but gave me the message
"Unable to establish connection to keystone endpoint." after I provided
admin/password.

Congress.  From the congress log I see connection errors happening for
keystone and neutron.

Looking at the Keystone screen log I don't see much of anything.  Here's
the API log in its entirety.  Seems it hasn't gotten any requests today
(Sept 28).

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "POST /v2.0/tokens HTTP/1.1"
200 4287 "-" "python-keystoneclient" 52799(us)

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "GET /v3/auth/tokens HTTP/1.1"
200 7655 "-" "python-keystoneclient" 65278(us)

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "POST /v2.0/tokens HTTP/1.1"
200 4287 "-" "python-keystoneclient" 63428(us)

10.1.184.61 - - [17/Sep/2015:12:05:08 -0700] "GET /v3/auth/tokens HTTP/1.1"
200 7655 "-" "python-keystoneclient" 135994(us)

10.1.184.61 - - [17/Sep/2015:12:05:09 -0700] "POST /v2.0/tokens HTTP/1.1"
200 4287 "-" "python-keystoneclient" 56581(us)

10.1.184.61 - - [17/Sep/2015:12:05:09 -0700] "GET /v3/auth/tokens HTTP/1.1"
200 7655 "-" "python-keystoneclient" 55412(us)

10.1.184.61 - - [17/Sep/2015:12:05:12 -0700] "GET /v2.0/users HTTP/1.1" 200
1679 "-" "python-keystoneclient" 13630(us)

10.1.184.61 - - [17/Sep/2015:12:05:12 -0700] "GET /v2.0/OS-KSADM/roles
HTTP/1.1" 200 397 "-" "python-keystoneclient" 10940(us)

10.1.184.61 - - [17/Sep/2015:12:05:12 -0700] "GET /v2.0/tenants HTTP/1.1"
200 752 "-" "python-keystoneclient" 12387(us)

The VM has eth0 bridged.  I can ping google.com from inside the VM; I can
ssh to the VM from my laptop.

Any ideas what's going on?  (I'm trying to unstack/clean/stack to see if
that works, but it'll take a while.)

Tim




On Thu, Sep 17, 2015 at 6:05 PM Alex Yip  wrote:

> Hi all,
> I have created a VirtualBox VM that matches the Vancouver handson-lab here:
>
>
> https://drive.google.com/file/d/0B94E7u1TIA8oTEdOQlFERkFwMUE/view?usp=sharing
>
> There's also an updated instruction document here:
>
>
> https://docs.google.com/document/d/1ispwf56bX8sy9T0KZyosdHrSR9WHEVA1oGEIYA22Orw/pub
>
> If you have some time, please try it out to see if it all works as
> expected.
> thanks, Alex
>
> __
> 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] [TripleO] tripleo.org theme

[Dan Prince]

On Mon, 2015-09-28 at 16:04 +, Jeremy Stanley wrote:
> On 2015-09-28 09:43:37 -0400 (-0400), James Slagle wrote:
> > Would the content of tripleo-docs be exactly the same as what is
> > published at http://docs.openstack.org/developer/tripleo-docs/ ?
> > 
> > I think it probably should be, and be updated on every merged
> > commit.
> > If that's not the case, I think it should be abundantly clear why
> > someone might would use one set of docs over the other.
> [...]
> 
> If you're looking at Project Infrastructure/Upstream CI integration
> with that site, I encourage you to just move remaining content to
> docs.openstack.org or possibly implement rewrites to something like
> tripleo.openstack.org.

docs.openstack.org is great too. We already use that for many things
and we aren't moving away from it. The only reason I wanted to include
tripleo-docs in this new themed site was simply that it highlights the
content a bit more. Front and central content w/ our mascot would be
quite nice... Just a different way to cut into TripleO...

tripleo.openstack.org would be cool too (perhaps in addition to
tripleo.org even). Having both point to the same thing would work quite
nice I think.

As for hosting tripleo.org I'm initially planning on hosting it outside
of Infra. I had previously asked about infra hosting the DNS domain
here and it sounded like the domain might not be the best fit:

http://lists.openstack.org/pipermail/openstack-infra/2015-May/002776.ht
ml

Moving it to be infra managed would be fine too. I've got no issues
with that should we agree that is the best place for it.

>  We've been doing the same for other "vanity"
> domains (see recent moves of devstack.org, refstack.org,
> trystack.org) so that we can get everything under a common base
> domain unless there is an actual technical requirement to have a
> separate domain (e.g. the cross-domain browser security concerns
> which drove us to register openstackid.org for our OpenID
> authentication).



__
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] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[John Griffith]

On Mon, Sep 28, 2015 at 12:11 PM, Duncan Thomas 
wrote:

> I can definitely see your logic, but we've a history in cinder of vendors
> trying to cram drivers in at the last minute which we very much wanted to
> stop dead. I might suggest that the second milestone, rather than the first
> might be a better one to dedicate to driver reviews...
>
​I guess we're not waiting until the summit :)  So honestly I think the
whole driver freeze thing should just be a part of the regular
feature-freeze rules and requirements.  If the code gets submitted late;
well the submitter runs the risk of it not getting reviewed and not making
it.  That's life, and no amount of PM's on IRC or email pleading for a
review really sway me in those cases.

We've given this weird expectation to folks that "if you submit X by date
Y, we guarantee it'll merge" which is not only inaccurate, but completely
unfair.  It needs to be clear that there is a 6 month (actually more like 4
or 5) cycle to get your code in.  The longer you wait, the less likely
everything will get reviewed and merged.​  Sorry, but that's how it goes; I
personally stopped treating drivers as 'special' submissions a while ago
and have no intention of going back to pretending they're something
"special".  They're just another feature add IMHO.


> An interesting thing is that, from the point of view of cinder core, we
> don't need more drivers. We've drivers coming out of our ears.
>

​True that!!!  What are we at like, 80 or something now?​

​  Anybody interested in this topic come chat with me at the summit
(shameless plug for Griffith's agendas on removing drivers from
cinder/volume/drivers..., or at least coming up with a different method of
implementing them)  :)

It's a hard problem, no easy answer.  I also argue that "good" drivers do
make Cinder better; but we shouldn't make calls on what's good and bad
other than code review.

Sure it is incrementally better to get more drivers, but we've got far more
> to gain from harnessing the developers of companies who want to merge new
> drivers for core work (or ci improvements, or translation or docs
> improvements or whatever) than we do from yet another driver. Increasing
> the bar for enter slightly does us no major harm that I can tell - there's
> a clear benefit from having your driver in tree, so if there's a small
> 'tax' to get added then I suspect we can benefit from it substantially.
>
> Definitely worth reviewing deadlines and other bureaucracy occasionally
> and working out if it is still serving us well.
> ​
>
>
>
Cheers
> On 28 Sep 2015 20:32, "Ben Swartzlander"  wrote:
>
>> I've always thought it was a bit strange to require new drivers to merge
>> by milestone 1. I think I understand the motivations of the policy. The
>> main motivation was to free up reviewers to review "other things" and this
>> policy guarantees that for 75% of the release reviewers don't have to
>> review new drivers. The other motivation was to prevent vendors from
>> turning up at the last minute with crappy drivers that needed a ton of
>> work, by encouraging them to get started earlier, or forcing them to wait
>> until the next cycle.
>>
>> I believe that the deadline actually does more harm than good.
>>
>> First of all, to those that don't want to spend time on driver reviews,
>> there are other solutions to that problem. Some people do want to review
>> the drivers, and those who don't can simply ignore them and spend time on
>> what they care about. I've heard people who spend time on driver reviews
>> say that the milestone-1 deadline doesn't mean they spend less time
>> reviewing drivers overall, it just all gets crammed into the beginning of
>> each release. It should be obvious that setting a deadline doesn't actually
>> affect the amount of reviewer effort, it just concentrates that effort.
>>
>> The argument about crappy code is also a lot weaker now that there are CI
>> requirements which force vendors to spend much more time up front and clear
>> a much higher quality bar before the driver is even considered for merging.
>> Drivers that aren't ready for merge can always be deferred to a later
>> release, but it seems weird to defer drivers that are high quality just
>> because they're submitted during milestones 2 or 3.
>>
>> All the the above is just my opinion though, and you shouldn't care about
>> my opinions, as I don't do much coding and reviewing in Cinder. There is a
>> real reason I'm writing this email...
>>
>> In Manila we added some major new features during Liberty. All of the new
>> features merged in the last week of L-3. It was a nightmare of merge
>> conflicts and angry core reviewers, and many contributors worked through a
>> holiday weekend to bring the release together. While asking myself how we
>> can avoid such a situation in the future, it became clear to me that bigger
>> features need to merge earlier -- the earlier the better.
>>
>> When I 

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

[Evgeniy L]

Hi Mike, thanks, now it's clear.

On Thu, Sep 3, 2015 at 9:19 AM, Mike Scherbakov 
wrote:

> Thank you all for the feedback.
>
>
> Dims -
>
> > 1) I'd advise to codify a proposal in fuel-specs under a 'policy'
> directory
>
> I think it's great idea and I'll do it.
>
>
> > 2) We don't have SME terminology, but we do have Maintainers both in
> oslo-incubator
>
> I like "Maintainers" more than SMEs, thank you for suggestion. I'd switch
> SME -> Maintainer everywhere.
>
>
> > 3) Is there a plan to split existing repos to more repos? Then each repo
> can have a core team (one core team for one repo), PTL takes care of all
> repos and MAINTAINERS take care of directories within a repo. That will
> line up well with what we are doing elsewhere in the community (essentially
> "Component Lead" is a core team which may not be a single person).
>
> That's the plan, with one difference though. According to you, there is a
> core team per repo without a lead identified. In my proposal, I'd like to
> ensure that we always choose a lead by the process of voting. I'd like to
> have voting process of identifying a component lead. It has to be fair
> process.
>
>
> > We do not have a concept of SLA anywhere that i know of, so it will have
> to be some kind of social consensus and not a real carrot/stick.
>
> > As for me the idea of SLA contradicts to qualitative reviews.
>
> I'm not thinking about carrot or stick here. I'd like to ensure that core
> reviewers and component leads are targeted to complete reviews within a
> certain time. If it doesn't happen, then patchset needs to be discussed
> during IRC meeting if we can delegate some testing, etc. to someone. If
> there are many patchsets out of SLA, then we'd consider other changes
> (decide to drop something from the release so to free up resources or
> something else).
>
> We had a problem in the past, when we would not pay attention to a patch
> proposed by someone before it's being escalated. I'm suggesting a solution
> for that problem. SLA is the contract between contributor and reviewer, and
> both would have same expectations on how long would it take to review the
> patch. Without expectations aligned, contributors can get upset easily.
> They may expect that their code will be reviewed and merged within hours,
> while it fact it's days. I'm not even talking about patches which can be
> forgotten and hang in the queue for months...
>
>
> > If we succeed in reducing the load on core reviewers, it will mean that
> core reviewers will do less code reviews. This could lead to core reviewer
> demotion.
>
> I expect that there will be a drop in code reviews being done by core
> reviewers team. This is the point actually - do less reviews, but do it
> more thoroughly. Don't work on patches which have easy mistakes, as those
> should be cought by maintainers, before these patches come to the core
> reviewer's plate. I don't think though that it will lead to core reviewer
> "demotion". Still, you will be doing many reviews - just less than before,
> and other who did a little - will do more reviews, potentially becoming
> joining a core team later.
>
>
> > It would be nice if Jenkins could add reviewers after CI +1, or we can
> use gerrit dashboard for SMEs to not waste their time on review that has
> not yet passed CI and does not have +1 from other reviewers.
>
> This is good suggestion. I agree.
>
>
> > AFAIK Boris Pavlovic introduced some scripts
>
> > in Rally which do basic preliminary check of review message, checking
>
> > that it's formally correct.
>
> Thanks Igor, I believe this can be applied as well.
>
>
> > Another thing is I got a bit confused by the difference between Core
> Reviewer and Component Lead,
>
> > aren't those the same persons? Shouldn't every Core Reviewer know the
> architecture, best practises
>
> > and participate in design architecture sessions?
>
> Component Lead is being elected by core reviewers team as the lead. So
> it's just another core reviewer / architect, but with the right to have a
> final word. Also, for large parts like fuel-library / nailgun, I'd expect
> this person to be free from any feature-work. For smaller things, like
> network verifier, I don't think that we'd need to have dedicated component
> owner who will be free from any feature work.
>
>
> Igor K., Evgeny L, did I address your questions regarding SLA and
> component lead vs core reviewer?
>
> Thank you,
>
> On Wed, Sep 2, 2015 at 9:28 AM Jay Pipes  wrote:
>
>> On 09/02/2015 08:45 AM, Igor Kalnitsky wrote:
>> >> I think there's plenty of examples of people in OpenStack projects
>> >> that both submit code (and lead features) that also do code review
>> >> on a daily basis.
>> >
>> > * Do these features huge?
>>
>> Yes.
>>
>> > * Is their code contribution huge or just small patches?
>>
>> Both.
>>
>> > * Did they get to master before FF?
>>
>> Yes.
>>
>> > * How many intersecting features OpenStack projects have 

Re: [openstack-dev] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[John Griffith]

On Mon, Sep 28, 2015 at 11:29 AM, Ben Swartzlander 
wrote:

> I've always thought it was a bit strange to require new drivers to merge
> by milestone 1. I think I understand the motivations of the policy. The
> main motivation was to free up reviewers to review "other things" and this
> policy guarantees that for 75% of the release reviewers don't have to
> review new drivers. The other motivation was to prevent vendors from
> turning up at the last minute with crappy drivers that needed a ton of
> work, by encouraging them to get started earlier, or forcing them to wait
> until the next cycle.
>

​Yep, these were some of the ideas behind it but the first milestone did
for sure create some consequences.​


>
> I believe that the deadline actually does more harm than good.
>

​In retrospect I'd agree with you on this.  We ended up spending our major
focus for the first milestone on nothing but drivers which I think looking
back wasn't so good.  But to be fair, we try things, see how they work,
revisit and move on.  Which is the plan last I checked (there's a proposal
to talk about some of this at the summit in Tokyo).​


>
> First of all, to those that don't want to spend time on driver reviews,
> there are other solutions to that problem. Some people do want to review
> the drivers, and those who don't can simply ignore them and spend time on
> what they care about. I've heard people who spend time on driver reviews
> say that the milestone-1 deadline doesn't mean they spend less time
> reviewing drivers overall, it just all gets crammed into the beginning of
> each release. It should be obvious that setting a deadline doesn't actually
> affect the amount of reviewer effort, it just concentrates that effort.
>

​True statement, although there was an effort to have core reviewer 'sign
up' and take ownership/responsibility specifically to review various
drivers.​


>
> The argument about crappy code is also a lot weaker now that there are CI
> requirements which force vendors to spend much more time up front and clear
> a much higher quality bar before the driver is even considered for merging.
> Drivers that aren't ready for merge can always be deferred to a later
> release, but it seems weird to defer drivers that are high quality just
> because they're submitted during milestones 2 or 3.
>
> All the the above is just my opinion though, and you shouldn't care about
> my opinions, as I don't do much coding and reviewing in Cinder. There is a
> real reason I'm writing this email...
>
> In Manila we added some major new features during Liberty. All of the new
> features merged in the last week of L-3. It was a nightmare of merge
> conflicts and angry core reviewers, and many contributors worked through a
> holiday weekend to bring the release together. While asking myself how we
> can avoid such a situation in the future, it became clear to me that bigger
> features need to merge earlier -- the earlier the better.
>

​So this is most certainly an issue that we've been having in Cinder as
well.  It's a bad problem to have in my opinion and also I personally took
a pretty hard stance against some new features, reworking of core code
because it wasn't ready until the last week or so of the milestone and
frankly they were HUGE changes.
​


>
> When I look at the release timeline, and ask myself when is the best time
> to merge new major features, and when is the best time to merge new
> drivers, it seems obvious that *features* need to happen early and drivers
> should come *later*. New major features require FAR more review time than
> new drivers, and they require testing, and even after they merge they cause
> merge conflicts that everyone else has to deal with. Better that that works
> happens in milestones 1 and 2 than right before feature freeze. New drivers
> can come in right before feature freeze as far as I'm concerned. Drivers
> don't cause merge conflicts, and drivers don't need huge amounts of testing
> (presumably the CI system ensure some level of quality).
>

​For the most part I think I completely agree with everything you've said
above.​


>
> It also occurs to me that new features which require driver implementation
> (hello replication!) *really* should go in during the first milestone so
> that drivers have time to implement the feature during the same release.
>

​Yep, I most certainly should have pushed this in to the core code MUCH
earlier.  But to be honest, if you look at the life-cycle of the spec and
the patch that implemented it; it was proposed very early, BUT there was
very little useful input until after the mid-cycle'ish meetup in FTC. Was
it a matter of review focus, bike-shedding, or me being lazy... maybe a
little of all three.​


>
> So I'm asking the Cinder core team to reconsider the milestone-1 deadline
> for drivers, and to change it to a deadline for new major features (in
> milestone-1 or milestone-2), and to allow drivers to merge whenever*. This

[openstack-dev] [election] [tc] TC candidacy

[Sean Dague]

I'd like to submit my candidacy for the TC Election.

I've been involved with OpenStack since the beginning of the Folsom
release. We may have worked together on parts of Nova, Tempest,
DevStack, Grenade, or in generally debugging failures in the upstream
gate in OpenStack. Or from things like the gerrit-dash-creator that
makes it easy for teams to build custom review dashboards.

I'm a strong believer in the Big Tent approach to OpenStack. I was one
of the early instigators of that conversation [1], which as with all
things got better with more smart people involved in it. I'm also a
strong believer that the longevity of the OpenStack project is about
having a solid and small on ramp that gets OpenStack in as many places
as possible. And a clear path to expand it over time. This was one of
the reasons I believed the compute-starter-kit was an important tag
that the TC bless [2].

Over the past year I've spent time on decomposing and modularizing
OpenStack components. We no longer test all the projects and all the
libraries in one giant gate queue. We now have a plugin framework for
DevStack and Grenade that makes it easier for people to expand on top
of it.

I've also been focusing on the API side of OpenStack. In the API
working group, and on the Nova project. I helped define the
Micro-version approach that is used in Nova, and has been adopted by
other projects in OpenStack [3]. This has opened up a new way for
projects to evolve their API while not breaking existing applications.

Over the next couple of cycles my focus is going to be interop, with
an eye on the Service Catalog and the API of projects. I hope to do
that work with a broad range of contributors to make the end user
experience of OpenStack much better.

In my role at Hewlett Packard I've got the freedom to work on many of
these larger issues in the way that works best for the community.

If this is the kind of voice that you would like on the TC, please
feel free to vote for me. It would be my honor and pleasure to
continue to represent you, and the mission to expand OpenStack's
reach, on the TC.

-Sean

--
Sean Dague
irc: sdague

1. https://dague.net/2014/08/26/openstack-as-layers/
2. http://governance.openstack.org/reference/tags/compute_starter_kit.html
3. https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/

Review history: https://review.openstack.org/#/q/reviewer:2750,n,z
Commit history: https://review.openstack.org/#/q/owner:2750,n,z
Stackalytics: http://stackalytics.com/?user_id=sdague
: https://www.openhub.net/accounts/sdague

--
Sean Dague
http://dague.net

--
Sean Dague
http://dague.net

__
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] [ironic] weekly subteam status report

[Ruby Loo]

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

(diff with Sep 21)
- Open: 135 (-1). 9 new (+2), 36 in progress (-5), 0 critical, 7 high (-5)
and 9 incomplete
- Nova bugs with Ironic tag: 24 (+1). 0 new, 0 critical, 1 high

dtantsur continues to ping people and unassign abandoned bugs


Neutron/Ironic work (jroll)

no major updates, code still being worked on


ironic-lib adoption (dtantsur)
==
dsvm gate is working (though non-voting) on ironic-lib, time to switch!
-  dtantsur: yeah, meanwhile I will check and decide on the
refactoring of ironic to use ironic-lib
-  dtantsur: I think faizan told he has patch almost ready.
- rameshg87 will have update by 9/29.


Nova Liaisons (jlvillal & mrda)
===
- No updates


Testing/Quality (jlvillal/lekha)
==
- Still waiting for feature freeze to be lifted from global requirements to
add mimic requirement. Pinged dhellman on IRC on 28-Sep-2015
- jlvillal will work on initial test directory re-organization on ironic
server for functional testing
- krtaylor to look at unit test coverage
- krtaylor to document real BM CI rollout for PowerKVM
- grenade upgrade testing status


Inspector (dtansur)
===
ironic-inspector 2.2.0 released
-
http://lists.openstack.org/pipermail/openstack-announce/2015-September/000659.html
- 3 blueprints finished, 14 bugs fixed
- stable/liberty was created from this release


Bifrost (TheJulia)
=
Gate fixed, release 0.0.1 cut last week.


webclient (krotscheck / betherly)
=
- discussions with Horizon last week assured that we should be able to work
with both Horizon and downstream team successfully
- discussions with Horizon downstream (HP) team have concluded that we will
meet half way to have a UX that does not 100% resemble the existing panels
but is not so different as to confuse users
- design underway currently for submission to UX team (Piet)
- panel creation underway
- Reviews have stalled out:
https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient,n,z


Drivers
==

DRAC (ifarkas/lucas)

no update - working on python-dracclient to reach feature parity with DRAC
driver


iRMC (naohirot)
--
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z
- Status: Reactive (solicited for core team's review)
- New boot driver interface for iRMC drivers (bp/new-boot-interface)
- Enhance Power Interface for Soft Reboot and NMI
(bp/enhance-power-interface-for-soft-reboot-and-nmi)
- iRMC out of band inspection (bp/ironic-node-properties-discovery)



Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
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] [Fuel] Fuel PTL Candidacy

[Vladimir Kuklin]

Fuelers

I am glad that Fuel is becoming more open as a project and is heading
towards Openstack BigTent which should allow our project to scale and
become one of the default OpenStack installers not only for a fraction of
end users but for a significant amount of OpenStack developers also.
Although Fuel is a fairly good toolchain, that allows you to set up a
cluster in a production-ready way, there is still a room for improvement as
we need to work on many things to scale to thousand of deployed nodes,
allow plugin developers to alter deployment workflow and input data in the
way the want and improve many other things which are still not the best in
the industry.

And as a someone who has been working on this project since its very
beginning, leading (which was very tiny several first months) so-called
Fuel Library team and working on all the deployment components I am very
familiar with all the existing issues we need to address in the first
place.

And so far I want to nominate myself for PTL position of Fuel project to be
able to lead the project towards its perfection.

I would like to outline the major points I am going to work on during this
half-year cadence

* General Standards of Decision Making (Meritocracy and Cold Numbers)

This assumes that each design decision on architecture must be applied
according to the sufficient data and expert analysis performed by subject
matter experts and cold and heartless machines that should run tests and
collect metrics of existing and proposed solutions to figure out the best
solution. Each decision on the new library or tool to choose must be
accompanied by clear report showing that this change actually makes
difference. I will start working on the unified toolchain and methodology
on how to make decisions immediately.

* HA Polishing (Finish It!)

This one has always been one of the strongest parts of Fuel and we are
using our own unique and innovative ways of deploying HA architecture.
Nevertheless, we still have many things to work on to make it perfect:

1) Fencing and power management facilities
2) Event-based cluster management and disaster handling
3) Node health monitoring
4) Many-many others

* Reference Architecture Changes (Simplicity and Focus on What Matters The
Most)

It seems pretty obvious that our reference architecture requires some
simplification and polishing. We have several key-value storages, we are
using several HTTP servers/proxies and so on.
This makes us support lots of stuff instead of concentrating on a 'golden'
set of tools and utilities and making them work perfectly.
I want to spend significant time on figuring out possible solutions for
redefining of our architecture based on aforementioned principles.

* Quality and Deployment Velocity (CI and QA improvements)

Although we are among the only projects who run very extensive set of tests
including for each commit into Fuel Library - we can still work on many
things for perfect QA and CI.
These are:

1) integration tests for all the components, e.g. run deployment for each
deployment-related component like nailgun, nailgun-agent, fuel-agent,
fuel-astute and others
2) significantly increase test coverage: e.g. cover each deployment task
with noop test, increase unit test coverage for all the Fuel-only modules
3) work on the ways of automated generation of test plans for each
particular feature and bugfix including regression, functional, scale,
stress and other types of tests
4) work on the way of introducing more granular tests for fuel deployment
components - we have an awesome framework to get faster feedback, written
by fuel QA team, but we have not yet integrated it into our CI

* Flexibility and Scalability (Plugin Development and User Experience)

We have a lot of work to do on orchestration and capabilities of our
deployment engine. We still need to think of how to apply fixes easily onto
already deployed environments, how to parallelize deployment on different
nodes as it takes more and more time when we have more roles in the cluster.

We need to think how to make regular cluster operations less invasive.

We need to work on ability to document and standardize all the interactions
between various components of Fuel, such as Nailgun and Fuel-Library. There
are many roadblocks in Nailgun which we need to get rid of and make all as
data-driven as possible allowing plugin developers an regular users to
alter deployment in the way the want by introducing.

We also need to work on our provisioning scalability parts such as moving
towards iPXE + peer2peer base image distribution.

* Documentation (Make It Clear)

It seems we have lots of good tools like our devops toolkit, noop tests and
other things. But this info is not available to external contributors and
plugin developers. Even Fuel engineers do not know everything about how
these tools work.  I am going to setup several webinars and write a dozen
of articles on how to develop and test Fuel.

* Community (Unleash The 

Re: [openstack-dev] [cinder] The Absurdity of the Milestone-1 Deadline for Drivers

[Walter A. Boring IV]

On 09/28/2015 10:29 AM, Ben Swartzlander wrote:
I've always thought it was a bit strange to require new drivers to 
merge by milestone 1. I think I understand the motivations of the 
policy. The main motivation was to free up reviewers to review "other 
things" and this policy guarantees that for 75% of the release 
reviewers don't have to review new drivers. The other motivation was 
to prevent vendors from turning up at the last minute with crappy 
drivers that needed a ton of work, by encouraging them to get started 
earlier, or forcing them to wait until the next cycle.


I believe that the deadline actually does more harm than good.
But harm to whom?   It certainly puts the pressure on driver developers 
to make sure they get involved in the Cinder community and get aware of 
when the deadlines are.
I believe it simply shifts the time in which drivers get into tree. My 
$0.02 of opinion is, that if a new driver developer misses the 
milestone, then they have the rest of the release to work on getting CI 
up and running and ready to go for the next release.   I'm not sure I 
see the harm to the Cinder community or the project.   It's a deadline 
that a driver developer has to be aware of and compensate for.  We've 
had how many drivers land in the last 2 releases using this 
requirement?  I believe it's somewhere of 20+ drivers?




First of all, to those that don't want to spend time on driver 
reviews, there are other solutions to that problem. Some people do 
want to review the drivers, and those who don't can simply ignore them 
and spend time on what they care about. I've heard people who spend 
time on driver reviews say that the milestone-1 deadline doesn't mean 
they spend less time reviewing drivers overall, it just all gets 
crammed into the beginning of each release. It should be obvious that 
setting a deadline doesn't actually affect the amount of reviewer 
effort, it just concentrates that effort.


The argument about crappy code is also a lot weaker now that there are 
CI requirements which force vendors to spend much more time up front 
and clear a much higher quality bar before the driver is even 
considered for merging. Drivers that aren't ready for merge can always 
be deferred to a later release, but it seems weird to defer drivers 
that are high quality just because they're submitted during milestones 
2 or 3.
I disagree here.  CI doesn't prevent you from having a crappy driver.  
Your driver just needs to pass CI tests.  CI ensures that your driver 
works, but doesn't ensure that it
really meats the core reviewers standards for code.  Do we care?  I 
think we do.  Having drivers talk directly to the db, or FC drivers 
missing the FCZM decorators for auto zoning, etc.




All the the above is just my opinion though, and you shouldn't care 
about my opinions, as I don't do much coding and reviewing in Cinder. 
There is a real reason I'm writing this email...


In Manila we added some major new features during Liberty. All of the 
new features merged in the last week of L-3. It was a nightmare of 
merge conflicts and angry core reviewers, and many contributors worked 
through a holiday weekend to bring the release together. While asking 
myself how we can avoid such a situation in the future, it became 
clear to me that bigger features need to merge earlier -- the earlier 
the better.


When I look at the release timeline, and ask myself when is the best 
time to merge new major features, and when is the best time to merge 
new drivers, it seems obvious that *features* need to happen early and 
drivers should come *later*. New major features require FAR more 
review time than new drivers, and they require testing, and even after 
they merge they cause merge conflicts that everyone else has to deal 
with. Better that that works happens in milestones 1 and 2 than right 
before feature freeze. New drivers can come in right before feature 
freeze as far as I'm concerned. Drivers don't cause merge conflicts, 
and drivers don't need huge amounts of testing (presumably the CI 
system ensure some level of quality).


It also occurs to me that new features which require driver 
implementation (hello replication!) *really* should go in during the 
first milestone so that drivers have time to implement the feature 
during the same release.


So I'm asking the Cinder core team to reconsider the milestone-1 
deadline for drivers, and to change it to a deadline for new major 
features (in milestone-1 or milestone-2), and to allow drivers to 
merge whenever*. This is the same pitch I'll be making to the Manila 
core team. I've been considering this idea for a few weeks now but I 
wanted to wait until after PTL elections to suggest it here.


-Ben Swartzlander


* I don't actually care if/when there is a driver deadline, what I 
care about is that reviewers are free during M-1 to work on 
reviewing/testing of features. The easiest way to achieve that seems 
to be moving the driver deadline.
I'm 

Re: [openstack-dev] [fuel] PTL & Component Leads elections

[Tomasz Napierala]

> On 18 Sep 2015, at 04:39, Sergey Lukjanov  wrote:
> 
> 
> Time line:
> 
> PTL elections
> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position
> * September 29 - October 8: PTL elections

Just a reminder that we have a deadline for candidates today.

Regards,
-- 
Tomasz 'Zen' Napierala
Product Engineering - Poland








__
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] -1 due to line length violation in commit messages

[Zane Bitter]

On 28/09/15 05:47, Gorka Eguileor wrote:

On 26/09, Morgan Fainberg wrote:

As a core (and former PTL) I just ignored commit message -1s unless there is 
something majorly wrong (no bug id where one is needed, etc).

I appreciate well formatted commits, but can we let this one go? This 
discussion is so far into the meta-bike-shedding (bike shedding about bike 
shedding commit messages) ... If a commit message is *that* bad a -1 (or just 
fixing it?) Might be worth it. However, if a commit isn't missing key info (bug 
id? Bp? Etc) and isn't one long incredibly unbroken sentence moving from topic 
to topic, there isn't a good reason to block the review.


+1


It is not worth having a bot -1 bad commits or even having gerrit muck with 
them. Let's do the job of the reviewer and actually review code instead of 
going crazy with commit messages.


+1


Sent via mobile



I have to disagree, as reviewers we have to make sure that guidelines
are followed, if we have an explicit guideline that states that
the limit length is 72 chars, I will -1 any patch that doesn't follow
the guideline, just as I would do with i18n guideline violations.


Apparently you're unaware of the definition of the word 'guideline'. 
It's a guide. If it were a hard-and-fast rule then we would have a bot 
enforcing it already.


Is there anything quite so frightening as a large group of people 
blindly enforcing rules with total indifference to any sense of 
overarching purpose?


A reminder that the reason for this guideline is to ensure that none of 
the broad variety of tools that are available in the Git ecosystem 
effectively become unusable with the OpenStack repos due to wildly 
inconsistent formatting. And of course, even that goal has to be 
balanced against our other goals, such as building a healthy community 
and occasionally shipping some software.


There are plenty of ways to achieve that goal other than blanket 
drive-by -1's for trivial inconsistencies in the formatting of 
individual commit messages. A polite comment and a link to the 
guidelines is a great way to educate new contributors. For core 
reviewers especially, a comment like that and a +1 review will *almost 
always* get you the change you want in double-quick time. (Any 
contributor who knows they are 30s work away from a +2 is going to be 
highly motivated.)



Typos are a completely different matter and they should not be grouped
together with guideline infringements.


"Violations"? "Infringements"? It's line wrapping, not a felony case.


I agree that it is a waste of time and resources when you have to -1 a
patch for this, but there multiple solutions, you can make sure your
editor does auto wrapping at the right length (I have mine configured
this way), or create a git-enforce policy with a client-side hook, or do
like Ihar is trying to do and push for a guideline change.

I don't mind changing the guideline to any other length, but as long as
it is 72 chars I will keep enforcing it, as it is not the place of
reviewers to decide which guidelines are worthy of being enforced and
which ones are not.


Of course it is.

If we're not here to use our brains, why are we here? Serious question. 
Feel free to use any definition of 'here'.



Cheers,
Gorka.




On Sep 26, 2015, at 21:19, Ian Wells  wrote:

Can I ask a different question - could we reject a few simple-to-check things 
on the push, like bad commit messages?  For things that take 2 seconds to fix 
and do make people's lives better, it's not that they're rejected, it's that 
the whole rejection cycle via gerrit review (push/wait for tests to run/check 
website/swear/find change/fix/push again) is out of proportion to the effort 
taken to fix it.


I would welcome a confirmation step - but *not* an outright rejection - 
that runs *locally* in git-review before the change is pushed. Right 
now, gerrit gives you a warning after the review is pushed, at which 
point it is too late.



It seems here that there's benefit to 72 line messages - not that everyone sees 
that benefit, but it is present - but it doesn't outweigh the current cost.


Yes, 72 columns is the correct guideline IMHO. It's used virtually 
throughout the Git ecosystem now. Back in the early days of Git it 
wasn't at all clear - should you have no line breaks at all and let each 
tool do its own soft line wrapping? If not, where should you wrap? Now 
there's a clear consensus that you hard wrap at 72. Vi wraps git commit 
messages at 72 by default.


The output of "git log" indents commit messages by four spaces, so 
anything longer than 76 gets ugly, hard-to-read line-wrapping. I've also 
noticed that Launchpad (or at least the bot that posts commit messages 
to Launchpad when patches merge) does a hard wrap at 72 characters.


A much better idea than modifying the guideline would be to put 
documentation on the wiki about how to set up your editor so that this 
is never an issue. You shouldn't even have to 

[openstack-dev] [puppet][murano] Launchpad project created

[Ekaterina Chernova]

Hi all,

as you know murano started creating puppet manifests.
They are located at the corresponding repository
[1]

And this is just a notification, that the separate project
 [2]to track puppet-related activities
is created and
puppet-openstack  [2] group is
selected as a maintainer.

Currently, there is just one bug there, but please, don't forget to triage
new bugs in this repository.

[1] - https://github.com/openstack/puppet-murano
[2] - https://launchpad.net/puppet-murano
[3] - https://launchpad.net/~puppet-openstack

Regards,
Kate.
__
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] [Congress] Congress Usecases VM

[Tim Hinrichs]

When I tried to import the image, it gave me an error.


Could not create the imported medium
'/Users/tim/VirtualBox
VMs/Congress_Usecases/Congress_Usecases_SEPT_25_2015-disk1.vmdk'
.

VMDK: Compressed image is corrupted
'/Congress_Usecases_SEPT_25_2015-disk1.vmdk' (VERR_ZIP_CORRUPTED).


Tim



On Fri, Sep 25, 2015 at 3:38 PM Shiv Haris  wrote:

> Thanks Alex, Zhou,
>
>
>
> I get errors from congress when I do a re-join. These errors seem to due
> to the order in which the services are coming up. Hence I still depend on
> running stack.sh after the VM is up and running. Please try out the new VM
> – also advise if you need to add any of your use cases. Also re-join starts
> “screen” – do we expect the end user to know how to use “screen”.
>
>
>
> I do understand that running “stack.sh” takes time to run – but it does
> not do things that appear to be any kind of magic which we want to avoid in
> order to get the user excited.
>
>
>
> I have uploaded a new version of the VM please experiment with this and
> let me know:
>
>
>
> http://paloaltan.net/Congress/Congress_Usecases_SEPT_25_2015.ova
>
>
>
> (root: vagrant password: vagrant)
>
>
>
> -Shiv
>
>
>
>
>
>
>
> *From:* Alex Yip [mailto:a...@vmware.com]
> *Sent:* Thursday, September 24, 2015 5:09 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> I was able to make devstack run without a network connection by disabling
> tempest.  So, I think it uses the loopback IP address, and that does not
> change, so rejoin-stack.sh works without a network at all.
>
>
>
> - Alex
>
>
>
>
> --
>
> *From:* Zhou, Zhenzan 
> *Sent:* Thursday, September 24, 2015 4:56 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Rejoin-stack.sh works only if its IP was not changed. So using NAT network
> and fixed ip inside the VM can help.
>
>
>
> BR
>
> Zhou Zhenzan
>
>
>
> *From:* Alex Yip [mailto:a...@vmware.com ]
> *Sent:* Friday, September 25, 2015 01:37
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> I have been using images, rather than snapshots.
>
>
>
> It doesn't take that long to start up.  First, I boot the VM which takes a
> minute or so.  Then I run rejoin-stack.sh which takes just another minute
> or so.  It's really not that bad, and rejoin-stack.sh restores vms and
> openstack state that was running before.
>
>
>
> - Alex
>
>
>
>
> --
>
> *From:* Shiv Haris 
> *Sent:* Thursday, September 24, 2015 10:29 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> Hi Congress folks,
>
>
>
> I am looking for ideas. We want the Openstack to be running when the user
> instantiates the Usecase-VM. However creating a OVA file is possible only
> when the VM is halted which means Openstack is not running and the user
> will have to run devstack again (which is time consuming) when the VM is
> restarted.
>
>
>
> The option is to take a snapshot. It appears that taking a snapshot of the
> VM and using it in another setup is not very straight forward. It involves
> modifying the .vbox file and seems that it is prone to user errors. I am
> leaning towards halting the machine and generating an OVA file.
>
>
>
> I am looking for suggestions ….
>
>
>
> Thanks,
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Shiv Haris [mailto:sha...@brocade.com ]
> *Sent:* Thursday, September 24, 2015 9:53 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> First of all I apologize for not making it at the meeting yesterday, could
> not cut short another overlapping meeting.
>
>
>
> Also, Tim thanks for the feedback. I have addressed some of the issues you
> posed however I am still working on some of the subtle issues raised. Once
> I have addressed all I will post another VM by end of the week.
>
>
>
> -Shiv
>
>
>
>
>
> *From:* Tim Hinrichs [mailto:t...@styra.com ]
> *Sent:* Friday, September 18, 2015 5:14 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Congress] Congress Usecases VM
>
>
>
> It's great to have this available!  I think it'll help people understand
> what's going on MUCH more quickly.
>
>
>
> Some thoughts.
>
> - The image is 3GB, which took me 30 minutes to download.  Are all VMs
> this big?  I think we should finish this as a VM but then look into doing
> it with containers to make it EVEN easier for people to get started.
>
>
>
> [shivharis] Yes, unfortunately that is the case. The disk size I set is
> 20GB – but 

Re: [openstack-dev] [all] Proposed Mitaka release schedule

[Doug Hellmann]

Excerpts from Ivan Kolodyazhny's message of 2015-09-28 17:41:46 +0300:
> Hi Thierry,
> 
> Thank you for sharing this information with us so early. One
> comment/question from me about FinalClientLibraryRelease:
> 
> Could we make client release at least one week later after M-3 milestone?
> It will give us more chances to have features landed into the client if
> they were merged late before M-3 and feature freeze.

The timeline in this schedule is more or less the same as what we've
done the past two cycles.  Allowing client feature work to carry
on longer in the schedule does not leave time for dealing with
issues introduced by buggy client releases.

I recommend prioritizing features that are going to require work
in the clients so those patches can land early enough to follow the
schedule, especially if those are features that other projects are
going to be depending on.

Doug

> 
> Regards,
> Ivan Kolodyazhny
> 
> On Mon, Sep 28, 2015 at 5:08 PM, Thierry Carrez 
> wrote:
> 
> > Hi everyone,
> >
> > You can find the proposed release schedule for Mitaka here:
> >
> > https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
> >
> > That places the end release on April 7, 2016. It's also worth noting
> > that in an effort to maximize development time, this schedule reduces
> > the time between Feature Freeze and final release by one week (5 weeks
> > instead of 6 weeks). That means we'll collectively have to be a lot
> > stricter on Feature freeze exceptions this time around. Be prepared for
> > that.
> >
> > Feel free to ping the Release management team members on
> > #openstack-relmgr-office if you have any question.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > 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][nova] how to upgrade from v1 to v2?

[Doug Hellmann]

Excerpts from Mark Voelker's message of 2015-09-28 19:55:18 +:
> On Sep 28, 2015, at 9:03 AM, Doug Hellmann  wrote:
> > 
> > Excerpts from John Garbutt's message of 2015-09-28 12:32:53 +0100:
> >> On 28 September 2015 at 12:10, Sean Dague  wrote:
> >>> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
>  Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
> > On Sep 25, 2015, at 1:56 PM, Doug Hellmann  
> > wrote:
> >> 
> >> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> >>> 
> > 
> > Ah.  Thanks for bringing that up, because I think this may be an area 
> > where there’s some misconception about what DefCore is set up to do 
> > today.  In it’s present form, the Board of Directors has structured 
> > DefCore to look much more at trailing indicators of market acceptance 
> > rather than future technical direction.  More on that over here. [1]
>  
>  And yet future technical direction does factor in, and I'm trying
>  to add a new heuristic to that aspect of consideration of tests:
>  Do not add tests that use proxy APIs.
>  
>  If there is some compelling reason to add a capability for which
>  the only tests use a proxy, that's important feedback for the
>  contributor community and tells us we need to improve our test
>  coverage. If the reason to use the proxy is that no one is deploying
>  the proxied API publicly, that is also useful feedback, but I suspect
>  we will, in most cases (glance is the exception), say "Yeah, that's
>  not how we mean for you to run the services long-term, so don't
>  include that capability."
> >>> 
> >>> I think we might also just realize that some of the tests are using the
> >>> proxy because... that's how they were originally written.
> >> 
> >> From my memory, thats how we got here.
> >> 
> >> The Nova tests needed to use an image API. (i.e. list images used to
> >> check the snapshot Nova, or similar)
> >> 
> >> The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
> >> it being the only widely deployed option.
> > 
> > Right, and I want to make sure it's clear that I am differentiating
> > between "these tests are bad" and "these tests are bad *for DefCore*".
> > We should definitely continue to test the proxy API, since it's a
> > feature we have and that our users rely on.
> > 
> >> 
> >>> And they could be rewritten to use native APIs.
> >> 
> >> +1
> >> Once Glance v2 is available.
> >> 
> >> Adding Glance v2 as advisory seems a good step to help drive more adoption.
> > 
> > I think we probably don't want to rewrite the existing tests, since
> > that effectively changes the contract out from under existing folks
> > complying with DefCore.  If we need new, parallel, tests that do
> > not use the proxy to make more suitable tests for DefCore to use,
> > we should create those.
> > 
> >> 
> >>> I do agree that "testing proxies" should not be part of Defcore, and I
> >>> like Doug's idea of making that a new heuristic in test selection.
> >> 
> >> +1
> >> Thats a good thing to add.
> >> But I don't think we had another option in this case.
> > 
> > We did have the option of leaving the feature out and highlighting the
> > discrepancy to the contributors so tests could be added. That
> > communication didn't really happen, as far as I can tell.
> > 
>  Sorry, I wasn't clear. The Nova team would, I expect, view the use of
>  those APIs in DefCore as a reason to avoid deprecating them in the code
>  even if they wanted to consider them as legacy features that should be
>  removed. Maybe that's not true, and the Nova team would be happy to
>  deprecate the APIs, but I did think that part of the feedback cycle we
>  were establishing here was to have an indication from the outside of the
>  contributor base about what APIs are considered important enough to keep
>  alive for a long period of time.
> >>> I'd also agree with this. Defcore is a wider contract that we're trying
> >>> to get even more people to write to because that cross section should be
> >>> widely deployed. So deprecating something in Defcore is something I
> >>> think most teams, Nova included, would be very reluctant to do. It's
> >>> just asking for breaking your users.
> >> 
> >> I can't see us removing the proxy APIs in Nova any time soon,
> >> regardless of DefCore, as it would break too many people.
> >> 
> >> But personally, I like dropping them from Defcore, to signal that the
> >> best practice is to use the Glance v2 API directly, rather than the
> >> Nova proxy.
> >> 
> >> Maybe the are just marked deprecated, but still required, although
> >> that sounds a bit crazy.
> > 
> > Marking them as deprecated, then removing them from DefCore, would let
> > the Nova team make a technical decision about what to do with them
> > (maybe they get spun out into a 

[openstack-dev] [Congress] Congress and Monasca Joint Session at Tokyo Design Summit

[Fabio Giannetti (fgiannet)]

Tim and Congress folks,
  I am writing on behalf of the Monasca community and I would like to explore 
the possibility of holding a joint session during the Tokyo Design Summit.
We would like to explore:

  1.  how to integrate Monasca with Congress so then Monasca can provide 
metrics, logs and event data for policy evaluation/enforcement
  2.  How to leverage Monasca alarming to automatically notify about statuses 
that may imply policy breach
  3.  How to automatically (if possible) convert policies (or subparts) into 
Monasca alarms.

Please point me to a submission page if I have to create a formal proposal for 
the topic and/or let me know other forms we can interact at the Summit.
Thanks in advance,
Fabio

[http://www.cisco.com/c/dam/assets/email-signature-tool/logo_06.png?ct=1430182397611]

Fabio Giannetti
Cloud Innovation Architect
Cisco Services
fgian...@cisco.com
Phone: +1 408 527 1134
Mobile: +1 408 854 0020


Cisco Systems, Inc.
285 W. Tasman Drive
San Jose
California
95134
United States
Cisco.com





[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you 
print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

Please click 
here for 
Company Registration Information.


__
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] [Ironic] Preparing for functional testing in Ironic. Will likely break any in-flight patches.

[Villalovos, John L]

Just to give a heads up to people. I have proposed the following patch:
https://review.openstack.org/228612

This moves the tests in ironic/tests/ to ironic/tests/unit/

Likely this patch will break most in-flight patches, so rebasing will be 
required when this patch goes in.

If you have any questions, please let me know.

Thanks,
John

__
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] -1 due to line length violation in commit messages

[Clint Byrum]

Excerpts from Kevin Benton's message of 2015-09-28 14:29:14 -0700:
> I think a blanket statement about what people's motivations are is not
> fair. We've seen in this thread that some people want to enforce the limit
> of 72 chars and it's not about padding their stats.
> 
> The issue here is that we have a guideline with a very specific number. If
> we don't care to enforce it, why do we even bother? "Please do this, unless
> you don't feel like it", is going to be hard for many people to review in a
> way that pleases everyone.
> 

Please do read said guidelines. "Must" would be used if it were to be
"enforced". It "should" be formatted that way.

> On Mon, Sep 28, 2015 at 11:00 PM, Assaf Muller  wrote:
> 
> >
> >
> > On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter  wrote:
> >
> >> On 28/09/15 05:47, Gorka Eguileor wrote:
> >>
> >>> On 26/09, Morgan Fainberg wrote:
> >>>
>  As a core (and former PTL) I just ignored commit message -1s unless
>  there is something majorly wrong (no bug id where one is needed, etc).
> 
>  I appreciate well formatted commits, but can we let this one go? This
>  discussion is so far into the meta-bike-shedding (bike shedding about 
>  bike
>  shedding commit messages) ... If a commit message is *that* bad a -1 (or
>  just fixing it?) Might be worth it. However, if a commit isn't missing 
>  key
>  info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
>  moving from topic to topic, there isn't a good reason to block the 
>  review.
> 
> >>>
> >> +1
> >>
> >> It is not worth having a bot -1 bad commits or even having gerrit muck
>  with them. Let's do the job of the reviewer and actually review code
>  instead of going crazy with commit messages.
> 
> >>>
> >> +1
> >>
> >> Sent via mobile
> 
> 
> >>> I have to disagree, as reviewers we have to make sure that guidelines
> >>> are followed, if we have an explicit guideline that states that
> >>> the limit length is 72 chars, I will -1 any patch that doesn't follow
> >>> the guideline, just as I would do with i18n guideline violations.
> >>>
> >>
> >> Apparently you're unaware of the definition of the word 'guideline'. It's
> >> a guide. If it were a hard-and-fast rule then we would have a bot enforcing
> >> it already.
> >>
> >> Is there anything quite so frightening as a large group of people blindly
> >> enforcing rules with total indifference to any sense of overarching 
> >> purpose?
> >>
> >> A reminder that the reason for this guideline is to ensure that none of
> >> the broad variety of tools that are available in the Git ecosystem
> >> effectively become unusable with the OpenStack repos due to wildly
> >> inconsistent formatting. And of course, even that goal has to be balanced
> >> against our other goals, such as building a healthy community and
> >> occasionally shipping some software.
> >>
> >> There are plenty of ways to achieve that goal other than blanket drive-by
> >> -1's for trivial inconsistencies in the formatting of individual commit
> >> messages.
> >
> >
> > The actual issue is that we as a community (Speaking of the Neutron
> > community at least) are stat-crazed. We have a fair number of contributors
> > that -1 for trivial issues to retain their precious stats with alarming
> > zeal. That is the real issue. All of these commit message issues,
> > translation mishaps,
> > comment typos etc are excuses for people to boost their stats without
> > contributing their time or energy in to the project. I am beyond bitter
> > about this
> > issue at this point.
> >
> > I'll say what I've always said about this issue: The review process is
> > about collaboration. I imagine that the author is sitting next to me, and
> > we're going
> > through the patch together for the purpose of improving it. Review
> > comments should be motivated by a thirst to improve the proposed code in a
> > real way,
> > not by your want or need to improve your stats on stackalytics. The latter
> > is an enormous waste of your time.
> >
> >
> >> A polite comment and a link to the guidelines is a great way to educate
> >> new contributors. For core reviewers especially, a comment like that and a
> >> +1 review will *almost always* get you the change you want in double-quick
> >> time. (Any contributor who knows they are 30s work away from a +2 is going
> >> to be highly motivated.)
> >>
> >> Typos are a completely different matter and they should not be grouped
> >>> together with guideline infringements.
> >>>
> >>
> >> "Violations"? "Infringements"? It's line wrapping, not a felony case.
> >>
> >> I agree that it is a waste of time and resources when you have to -1 a
> >>> patch for this, but there multiple solutions, you can make sure your
> >>> editor does auto wrapping at the right length (I have mine configured
> >>> this way), or create a git-enforce policy with a client-side hook, or do
> >>> like Ihar 

Re: [openstack-dev] [Congress] Congress and Monasca Joint Session at Tokyo Design Summit

[Tim Hinrichs]

Hi Fabio: Thanks for reaching out.  We should definitely talk at the
summit.  I don't know if we can devote 1 of the 3 allocated Congress
sessions to Monasca, but we'll talk it over during IRC on Wed and let you
know.  Or do you have a session we could use for the discussion?  In any
case, I'm confident we can make good progress toward integrating Congress
and Monasca in Tokyo.  Monasca sounds interesting--I'm looking forward to
learning more!

Congress team: if we could all quickly browse the Monasca wiki before Wed's
IRC, that would be great:
https://wiki.openstack.org/wiki/Monasca

Tim



On Mon, Sep 28, 2015 at 1:50 PM Fabio Giannetti (fgiannet) <
fgian...@cisco.com> wrote:

> Tim and Congress folks,
>   I am writing on behalf of the Monasca community and I would like to
> explore the possibility of holding a joint session during the Tokyo Design
> Summit.
> We would like to explore:
>
>1. how to integrate Monasca with Congress so then Monasca can provide
>metrics, logs and event data for policy evaluation/enforcement
>2. How to leverage Monasca alarming to automatically notify about
>statuses that may imply policy breach
>3. How to automatically (if possible) convert policies (or subparts)
>into Monasca alarms.
>
> Please point me to a submission page if I have to create a formal proposal
> for the topic and/or let me know other forms we can interact at the Summit.
> Thanks in advance,
> Fabio
>
> *Fabio Giannetti*
> Cloud Innovation Architect
> Cisco Services
> fgian...@cisco.com
> Phone: *+1 408 527 1134*
> Mobile: *+1 408 854 0020*
>
> *Cisco Systems, Inc.*
> 285 W. Tasman Drive
> San Jose
> California
> 95134
> United States
> Cisco.com 
>
>  Think before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> Please click here
>  for
> Company Registration Information.
>
> __
> 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] [fuel] PTL Candidacy

[Dmitry Borodaenko]

I'd like to announce my candidacy as Fuel PTL for the next cycle.

It is our very first election, so we are taking our time to make sure we
get everything right. We have extended the nomination period to
September 28 [0] to give Fuel contributors more time to learn about the
OpenStack governance process [1] and discuss how it is going to apply to
Fuel [2].

[0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015#Timeline
[1] https://wiki.openstack.org/wiki/Governance
[2] 
http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-09-24-16.02.log.html#l-91

Fuel is a large project with well defined component boundaries. Some of
these components are as large and as active as whole other OpenStack
projects [3]. To improve our ability to cope with code review, design
review, and dispute resolution, we're introducing a role of a Component
Lead for the two largest components, and a team structure policy [4]
that will help new contributors find the right people for each stage of
our development process: from discussing ideas to reaching consensus
about design to getting the implementation reviewed and merged.

[3] https://lwn.net/Articles/648610/
[4] https://review.openstack.org/225376

Electing a PTL is an important step towards more open governance,
development, and community collaboration. Still, it is only one step,
and while we have made significant progress this year, there is still a
lot of work to be done before we can meet all the requirements of
becoming an official OpenStack project [5].

[5] https://review.openstack.org/199232

Specifically, we need to eliminate code duplication with Puppet
OpenStack project, and bring all our git repositories in compliance with
the Project Testing Interface, before bringing our proposal to join the
Big Tent back to the attention of the Technical Committee.

I think that in the next six months we should focus on the following:

- Continue improving our collaboration with Puppet OpenStack project and
  complete the migration from local forked copies to reusing upstream
  Puppet modules with librarian-puppet-simple.

- Collaborate with other OpenStack projects, most importantly RPM and
  DEB Packaging, OpenStack Infrastructure, and Documentation.

- Implement PTI [6] for all Fuel components and get commits to all our
  repositories gated with unit tests (as well as functional and
  integration tests where possible) on OpenStack Infrastructure.

  [6] http://governance.openstack.org/reference/project-testing-interface.html

- Continue and expand modularization efforts on all levels for better
  reuse of Fuel components both internally and in other projects. Follow
  fuel-agent [7] as the first example of how to extract parts of
  fuel-web into self-sufficient sub-projects. Expand applicability of
  plugins [8], deployment tasks [9], and network templates [10] to make
  it easier to adapt Fuel for different use cases.

  [7] 
https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html#fuel-agent
  [8] https://wiki.openstack.org/wiki/Fuel/Plugins
  [9] 
https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html#task-based-deployment
  [10] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking

- Expand Fuel developers documentation [11] and wiki [12], populate more
  of our component README files with information for contributors.
  Unsurprisingly, README.md in fuel-docs is a good example of that [13].

  [11] https://docs.fuel-infra.org/fuel-dev/
  [12] https://wiki.openstack.org/wiki/Fuel/How_to_contribute
  [13] https://github.com/stackforge/fuel-docs/blob/master/README.md

- Make our decision making process more transparent. We are already
  using fuel-specs repository [14] to discuss design specifications for
  Fuel bluprints, we should use openstack-dev and IRC more actively to
  include more people from OpenStack community in our technical
  discussions.

  [14] http://specs.fuel-infra.org/fuel-specs-master/

I have long advocated for more collaboration with the free software
community, and I strongly believe that paying close attention to
feedback from the community, encouraging new contributors, and building
a healthy and diverse community around Fuel is the best way to make Fuel
the awesomest OpenStack deployment tool for everyone.

[15] https://lists.launchpad.net/fuel-dev/msg00727.html

Thank you for your consideration,

-- 
Dmitry Borodaenko

__
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] devstack default worker changes

[Jay Pipes]

This is great news indeed, Sean. :)

On 09/28/2015 04:02 PM, Sean Dague wrote:

We used to default to using the mysqldb driver in devstack, which is a C
binding that is not eventlet aware. This means that any time a db query
is executed the entire greenlet is blocked. This behavior meant that in
devstack (and in oslo.concurrency) default number of workers for things
like API servers and conductors was = num of cores on the machine so
that everything wouldn't be deadlocked all the time when touching the
database.

The downside is we fixed concurrency with memory, which means you have a
lot of idle python eating all your memory all the time. Devstack in 4GB
isn't really an option any more with more than a small number of
services turned on.

We changed the default mysql driver to the pure python one back early in
Liberty. It shook out some bugs, but things got good quickly on that.
Just recently we decided to see if we could drop the worker count as
well in upstream devstack and gate jobs.

The new math will give you numproc / 4 workers for these services (min
of 2). This seems to be running fine. More interestingly it ends up
keeping an extra 1GB+ of memory in page cache by the end of the gate
runs, which seems to be making things a bit more stable, and under less
load. ( https://review.openstack.org/#/c/226831/ )

We've not seen any down side of this change yet, and it should make it
easier to get devstack into a smaller footprint VM. However, I wanted to
make sure people knew it was a change in case they see some new edge
failure condition that could be related to it.

So, it should mostly all be flowers and unicorns. But, keep an eye out
in case a troll shows up under a bridge somewhere.

-Sean



__
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] -1 due to line length violation in commit messages

[Kevin Benton]

I think a blanket statement about what people's motivations are is not
fair. We've seen in this thread that some people want to enforce the limit
of 72 chars and it's not about padding their stats.

The issue here is that we have a guideline with a very specific number. If
we don't care to enforce it, why do we even bother? "Please do this, unless
you don't feel like it", is going to be hard for many people to review in a
way that pleases everyone.

On Mon, Sep 28, 2015 at 11:00 PM, Assaf Muller  wrote:

>
>
> On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter  wrote:
>
>> On 28/09/15 05:47, Gorka Eguileor wrote:
>>
>>> On 26/09, Morgan Fainberg wrote:
>>>
 As a core (and former PTL) I just ignored commit message -1s unless
 there is something majorly wrong (no bug id where one is needed, etc).

 I appreciate well formatted commits, but can we let this one go? This
 discussion is so far into the meta-bike-shedding (bike shedding about bike
 shedding commit messages) ... If a commit message is *that* bad a -1 (or
 just fixing it?) Might be worth it. However, if a commit isn't missing key
 info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
 moving from topic to topic, there isn't a good reason to block the review.

>>>
>> +1
>>
>> It is not worth having a bot -1 bad commits or even having gerrit muck
 with them. Let's do the job of the reviewer and actually review code
 instead of going crazy with commit messages.

>>>
>> +1
>>
>> Sent via mobile


>>> I have to disagree, as reviewers we have to make sure that guidelines
>>> are followed, if we have an explicit guideline that states that
>>> the limit length is 72 chars, I will -1 any patch that doesn't follow
>>> the guideline, just as I would do with i18n guideline violations.
>>>
>>
>> Apparently you're unaware of the definition of the word 'guideline'. It's
>> a guide. If it were a hard-and-fast rule then we would have a bot enforcing
>> it already.
>>
>> Is there anything quite so frightening as a large group of people blindly
>> enforcing rules with total indifference to any sense of overarching purpose?
>>
>> A reminder that the reason for this guideline is to ensure that none of
>> the broad variety of tools that are available in the Git ecosystem
>> effectively become unusable with the OpenStack repos due to wildly
>> inconsistent formatting. And of course, even that goal has to be balanced
>> against our other goals, such as building a healthy community and
>> occasionally shipping some software.
>>
>> There are plenty of ways to achieve that goal other than blanket drive-by
>> -1's for trivial inconsistencies in the formatting of individual commit
>> messages.
>
>
> The actual issue is that we as a community (Speaking of the Neutron
> community at least) are stat-crazed. We have a fair number of contributors
> that -1 for trivial issues to retain their precious stats with alarming
> zeal. That is the real issue. All of these commit message issues,
> translation mishaps,
> comment typos etc are excuses for people to boost their stats without
> contributing their time or energy in to the project. I am beyond bitter
> about this
> issue at this point.
>
> I'll say what I've always said about this issue: The review process is
> about collaboration. I imagine that the author is sitting next to me, and
> we're going
> through the patch together for the purpose of improving it. Review
> comments should be motivated by a thirst to improve the proposed code in a
> real way,
> not by your want or need to improve your stats on stackalytics. The latter
> is an enormous waste of your time.
>
>
>> A polite comment and a link to the guidelines is a great way to educate
>> new contributors. For core reviewers especially, a comment like that and a
>> +1 review will *almost always* get you the change you want in double-quick
>> time. (Any contributor who knows they are 30s work away from a +2 is going
>> to be highly motivated.)
>>
>> Typos are a completely different matter and they should not be grouped
>>> together with guideline infringements.
>>>
>>
>> "Violations"? "Infringements"? It's line wrapping, not a felony case.
>>
>> I agree that it is a waste of time and resources when you have to -1 a
>>> patch for this, but there multiple solutions, you can make sure your
>>> editor does auto wrapping at the right length (I have mine configured
>>> this way), or create a git-enforce policy with a client-side hook, or do
>>> like Ihar is trying to do and push for a guideline change.
>>>
>>> I don't mind changing the guideline to any other length, but as long as
>>> it is 72 chars I will keep enforcing it, as it is not the place of
>>> reviewers to decide which guidelines are worthy of being enforced and
>>> which ones are not.
>>>
>>
>> Of course it is.
>>
>> If we're not here to use our brains, why are we here? Serious question.
>> Feel free to use 

Re: [openstack-dev] [lbaas] [octavia] Proposing new meeting time Wednesday 16:00 UTC

[Eichberger, German]

Brandon,

We had some requests in the past and I just wanted to float the idea on
the ML since we are starting a new cycle...

Thanks,
German

On 9/27/15, 10:12 PM, "Brandon Logan"  wrote:

>Is there a lot of people requesting this meeting change?
>
>Thanks,
>Brandon
>
>On Fri, 2015-09-25 at 23:58 +, Eichberger, German wrote:
>> All,
>> 
>> In our last meeting [1] we discussed moving the meeting earlier to
>> accommodate participants from the EMEA region. I am therefore proposing
>>to
>> move the meeting to 16:00 UTC on Wednesday. Please respond to this
>>e-mail
>> if you have alternate suggestions. I will send out another e-mail
>> announcing the new time and the date we will start with that.
>> 
>> Thanks,
>> German
>> 
>> [1] 
>> 
>>http://eavesdrop.openstack.org/meetings/octavia/2015/octavia.2015-09-23-2
>>0.
>> 00.log.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 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] [release][requirements] changes to the requirements-core team

[Doug Hellmann]

It has been a while since we've reviewed the requirements-core team
members. Since it's the end of the cycle, I did a quick scan of the
stats this week and I am proposing some changes based on participation.

I spoke with Ghe Rivero and Julien Danjou, both of whom have done good
work in the past but who have changed their focus more recently. Both
agreed that it no longer made sense to have them on the core team, so I
will remove them today. As with other core teams, renewed interest from
past cores is usually handled by fast-tracking them back onto the team.
Thank you, Ghe and Julien, for your contributions!

I also spoke with Davanum Srinivas (dims) about joining the team. He has
been active this cycle with requirements reviews and related release
work, and is interested in being more involved. The usual practice is to
wait a few days for feedback before adding someone new, so I will wait a
few days before adding dims.

Doug

__
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] -1 due to line length violation in commit messages

[Assaf Muller]

On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter  wrote:

> On 28/09/15 05:47, Gorka Eguileor wrote:
>
>> On 26/09, Morgan Fainberg wrote:
>>
>>> As a core (and former PTL) I just ignored commit message -1s unless
>>> there is something majorly wrong (no bug id where one is needed, etc).
>>>
>>> I appreciate well formatted commits, but can we let this one go? This
>>> discussion is so far into the meta-bike-shedding (bike shedding about bike
>>> shedding commit messages) ... If a commit message is *that* bad a -1 (or
>>> just fixing it?) Might be worth it. However, if a commit isn't missing key
>>> info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
>>> moving from topic to topic, there isn't a good reason to block the review.
>>>
>>
> +1
>
> It is not worth having a bot -1 bad commits or even having gerrit muck
>>> with them. Let's do the job of the reviewer and actually review code
>>> instead of going crazy with commit messages.
>>>
>>
> +1
>
> Sent via mobile
>>>
>>>
>> I have to disagree, as reviewers we have to make sure that guidelines
>> are followed, if we have an explicit guideline that states that
>> the limit length is 72 chars, I will -1 any patch that doesn't follow
>> the guideline, just as I would do with i18n guideline violations.
>>
>
> Apparently you're unaware of the definition of the word 'guideline'. It's
> a guide. If it were a hard-and-fast rule then we would have a bot enforcing
> it already.
>
> Is there anything quite so frightening as a large group of people blindly
> enforcing rules with total indifference to any sense of overarching purpose?
>
> A reminder that the reason for this guideline is to ensure that none of
> the broad variety of tools that are available in the Git ecosystem
> effectively become unusable with the OpenStack repos due to wildly
> inconsistent formatting. And of course, even that goal has to be balanced
> against our other goals, such as building a healthy community and
> occasionally shipping some software.
>
> There are plenty of ways to achieve that goal other than blanket drive-by
> -1's for trivial inconsistencies in the formatting of individual commit
> messages.


The actual issue is that we as a community (Speaking of the Neutron
community at least) are stat-crazed. We have a fair number of contributors
that -1 for trivial issues to retain their precious stats with alarming
zeal. That is the real issue. All of these commit message issues,
translation mishaps,
comment typos etc are excuses for people to boost their stats without
contributing their time or energy in to the project. I am beyond bitter
about this
issue at this point.

I'll say what I've always said about this issue: The review process is
about collaboration. I imagine that the author is sitting next to me, and
we're going
through the patch together for the purpose of improving it. Review comments
should be motivated by a thirst to improve the proposed code in a real way,
not by your want or need to improve your stats on stackalytics. The latter
is an enormous waste of your time.


> A polite comment and a link to the guidelines is a great way to educate
> new contributors. For core reviewers especially, a comment like that and a
> +1 review will *almost always* get you the change you want in double-quick
> time. (Any contributor who knows they are 30s work away from a +2 is going
> to be highly motivated.)
>
> Typos are a completely different matter and they should not be grouped
>> together with guideline infringements.
>>
>
> "Violations"? "Infringements"? It's line wrapping, not a felony case.
>
> I agree that it is a waste of time and resources when you have to -1 a
>> patch for this, but there multiple solutions, you can make sure your
>> editor does auto wrapping at the right length (I have mine configured
>> this way), or create a git-enforce policy with a client-side hook, or do
>> like Ihar is trying to do and push for a guideline change.
>>
>> I don't mind changing the guideline to any other length, but as long as
>> it is 72 chars I will keep enforcing it, as it is not the place of
>> reviewers to decide which guidelines are worthy of being enforced and
>> which ones are not.
>>
>
> Of course it is.
>
> If we're not here to use our brains, why are we here? Serious question.
> Feel free to use any definition of 'here'.
>
> Cheers,
>> Gorka.
>>
>>
>>
>> On Sep 26, 2015, at 21:19, Ian Wells  wrote:

 Can I ask a different question - could we reject a few simple-to-check
 things on the push, like bad commit messages?  For things that take 2
 seconds to fix and do make people's lives better, it's not that they're
 rejected, it's that the whole rejection cycle via gerrit review (push/wait
 for tests to run/check website/swear/find change/fix/push again) is out of
 proportion to the effort taken to fix it.

>>>
> I would welcome a confirmation step - but *not* an outright rejection -
> 

Re: [openstack-dev] [release][requirements] changes to the requirements-core team

[Robert Collins]

All sounds good to me.

-Rob

On 29 September 2015 at 09:16, Doug Hellmann  wrote:
> It has been a while since we've reviewed the requirements-core team
> members. Since it's the end of the cycle, I did a quick scan of the
> stats this week and I am proposing some changes based on participation.
>
> I spoke with Ghe Rivero and Julien Danjou, both of whom have done good
> work in the past but who have changed their focus more recently. Both
> agreed that it no longer made sense to have them on the core team, so I
> will remove them today. As with other core teams, renewed interest from
> past cores is usually handled by fast-tracking them back onto the team.
> Thank you, Ghe and Julien, for your contributions!
>
> I also spoke with Davanum Srinivas (dims) about joining the team. He has
> been active this cycle with requirements reviews and related release
> work, and is interested in being more involved. The usual practice is to
> wait a few days for feedback before adding someone new, so I will wait a
> few days before adding dims.
>
> Doug
>
> __
> 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



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
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] [release][requirements] changes to the requirements-core team

[Sean Dague]

On 09/28/2015 04:16 PM, Doug Hellmann wrote:
> It has been a while since we've reviewed the requirements-core team
> members. Since it's the end of the cycle, I did a quick scan of the
> stats this week and I am proposing some changes based on participation.
> 
> I spoke with Ghe Rivero and Julien Danjou, both of whom have done good
> work in the past but who have changed their focus more recently. Both
> agreed that it no longer made sense to have them on the core team, so I
> will remove them today. As with other core teams, renewed interest from
> past cores is usually handled by fast-tracking them back onto the team.
> Thank you, Ghe and Julien, for your contributions!
> 
> I also spoke with Davanum Srinivas (dims) about joining the team. He has
> been active this cycle with requirements reviews and related release
> work, and is interested in being more involved. The usual practice is to
> wait a few days for feedback before adding someone new, so I will wait a
> few days before adding dims.

All seems reasonable, +1.

-Sean

-- 
Sean Dague
http://dague.net

__
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] -1 due to line length violation in commit messages

[Clint Byrum]

Excerpts from Morgan Fainberg's message of 2015-09-26 23:36:09 -0700:
> As a core (and former PTL) I just ignored commit message -1s unless there is 
> something majorly wrong (no bug id where one is needed, etc). 
> 
> I appreciate well formatted commits, but can we let this one go? This 
> discussion is so far into the meta-bike-shedding (bike shedding about bike 
> shedding commit messages) ... If a commit message is *that* bad a -1 (or just 
> fixing it?) Might be worth it. However, if a commit isn't missing key info 
> (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence moving from 
> topic to topic, there isn't a good reason to block the review. 
> 
> It is not worth having a bot -1 bad commits or even having gerrit muck with 
> them. Let's do the job of the reviewer and actually review code instead of 
> going crazy with commit messages. 
> 

Agreed with all of your sentiments.

Please anyone -1'ing for this, read this:

https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_Git_commit_message_structure


"The first line should be limited to 50 characters and should not end
with a period (commit messages over 72 characters will be rejected by
the gate)."

"Subsequent lines should be wrapped at 72 characters."

Notice, the word "should" is used, not "must".

So _DO NOT_ -1 for this. A "should" is a guideline, and a note like
"hey could you wrap at 72 chars if you push again? We like to keep them
formatted that way, see [link] for more info. Thanks! #notAMinusOne"

Please can we not spend another minute on this? Thanks!

__
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] -1 due to line length violation in commit messages

[Kyle Mestery]

On Mon, Sep 28, 2015 at 4:00 PM, Assaf Muller  wrote:

>
>
> On Mon, Sep 28, 2015 at 12:40 PM, Zane Bitter  wrote:
>
>> On 28/09/15 05:47, Gorka Eguileor wrote:
>>
>>> On 26/09, Morgan Fainberg wrote:
>>>
 As a core (and former PTL) I just ignored commit message -1s unless
 there is something majorly wrong (no bug id where one is needed, etc).

 I appreciate well formatted commits, but can we let this one go? This
 discussion is so far into the meta-bike-shedding (bike shedding about bike
 shedding commit messages) ... If a commit message is *that* bad a -1 (or
 just fixing it?) Might be worth it. However, if a commit isn't missing key
 info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence
 moving from topic to topic, there isn't a good reason to block the review.

>>>
>> +1
>>
>> It is not worth having a bot -1 bad commits or even having gerrit muck
 with them. Let's do the job of the reviewer and actually review code
 instead of going crazy with commit messages.

>>>
>> +1
>>
>> Sent via mobile


>>> I have to disagree, as reviewers we have to make sure that guidelines
>>> are followed, if we have an explicit guideline that states that
>>> the limit length is 72 chars, I will -1 any patch that doesn't follow
>>> the guideline, just as I would do with i18n guideline violations.
>>>
>>
>> Apparently you're unaware of the definition of the word 'guideline'. It's
>> a guide. If it were a hard-and-fast rule then we would have a bot enforcing
>> it already.
>>
>> Is there anything quite so frightening as a large group of people blindly
>> enforcing rules with total indifference to any sense of overarching purpose?
>>
>> A reminder that the reason for this guideline is to ensure that none of
>> the broad variety of tools that are available in the Git ecosystem
>> effectively become unusable with the OpenStack repos due to wildly
>> inconsistent formatting. And of course, even that goal has to be balanced
>> against our other goals, such as building a healthy community and
>> occasionally shipping some software.
>>
>> There are plenty of ways to achieve that goal other than blanket drive-by
>> -1's for trivial inconsistencies in the formatting of individual commit
>> messages.
>
>
> The actual issue is that we as a community (Speaking of the Neutron
> community at least) are stat-crazed. We have a fair number of contributors
> that -1 for trivial issues to retain their precious stats with alarming
> zeal. That is the real issue. All of these commit message issues,
> translation mishaps,
> comment typos etc are excuses for people to boost their stats without
> contributing their time or energy in to the project. I am beyond bitter
> about this
> issue at this point.
>
>
I should note that as the previous PTL, for the most part I viewed stats as
garbage. Keep in mind I nominated two new core reviewers whose stats were
lowe but who are incredibly important members of our community [1]. I did
this because they are the type of people to be core reviewers, and we had a
long conversation on this. So, I agree with you, this stats thing is awful.
And Stackalytics hasn't helped it, but made it much worse.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-August/071869.html


> I'll say what I've always said about this issue: The review process is
> about collaboration. I imagine that the author is sitting next to me, and
> we're going
> through the patch together for the purpose of improving it. Review
> comments should be motivated by a thirst to improve the proposed code in a
> real way,
> not by your want or need to improve your stats on stackalytics. The latter
> is an enormous waste of your time.
>
>
>> A polite comment and a link to the guidelines is a great way to educate
>> new contributors. For core reviewers especially, a comment like that and a
>> +1 review will *almost always* get you the change you want in double-quick
>> time. (Any contributor who knows they are 30s work away from a +2 is going
>> to be highly motivated.)
>>
>> Typos are a completely different matter and they should not be grouped
>>> together with guideline infringements.
>>>
>>
>> "Violations"? "Infringements"? It's line wrapping, not a felony case.
>>
>> I agree that it is a waste of time and resources when you have to -1 a
>>> patch for this, but there multiple solutions, you can make sure your
>>> editor does auto wrapping at the right length (I have mine configured
>>> this way), or create a git-enforce policy with a client-side hook, or do
>>> like Ihar is trying to do and push for a guideline change.
>>>
>>> I don't mind changing the guideline to any other length, but as long as
>>> it is 72 chars I will keep enforcing it, as it is not the place of
>>> reviewers to decide which guidelines are worthy of being enforced and
>>> which ones are not.
>>>
>>
>> Of course it is.
>>
>> If we're not here to use our 

Re: [openstack-dev] [all] devstack default worker changes

[Matt Riedemann]

On 9/28/2015 3:02 PM, Sean Dague wrote:

We used to default to using the mysqldb driver in devstack, which is a C
binding that is not eventlet aware. This means that any time a db query
is executed the entire greenlet is blocked. This behavior meant that in
devstack (and in oslo.concurrency) default number of workers for things
like API servers and conductors was = num of cores on the machine so
that everything wouldn't be deadlocked all the time when touching the
database.

The downside is we fixed concurrency with memory, which means you have a
lot of idle python eating all your memory all the time. Devstack in 4GB
isn't really an option any more with more than a small number of
services turned on.

We changed the default mysql driver to the pure python one back early in
Liberty. It shook out some bugs, but things got good quickly on that.
Just recently we decided to see if we could drop the worker count as
well in upstream devstack and gate jobs.

The new math will give you numproc / 4 workers for these services (min
of 2). This seems to be running fine. More interestingly it ends up
keeping an extra 1GB+ of memory in page cache by the end of the gate
runs, which seems to be making things a bit more stable, and under less
load. ( https://review.openstack.org/#/c/226831/ )

We've not seen any down side of this change yet, and it should make it
easier to get devstack into a smaller footprint VM. However, I wanted to
make sure people knew it was a change in case they see some new edge
failure condition that could be related to it.

So, it should mostly all be flowers and unicorns. But, keep an eye out
in case a troll shows up under a bridge somewhere.

-Sean



The large ops job appears to be throwing up on itself a bit because of 
this change.  Tracking with bug 
https://bugs.launchpad.net/nova/+bug/1500615.


--

Thanks,

Matt Riedemann


__
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] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Kyle Mestery]

The Neutron team also discussed this in Vancouver, you can see the etherpad
here [1]. We talked about the idea of creating a validation suite, and it
sounds like that's something we should again discuss in Tokyo for the
Mitaka cycle. I think a validation suite would be a great step forward for
Neutron third-party CI systems to use to validate they work with a release.

[1] https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty

On Sun, Sep 27, 2015 at 11:39 AM, Armando M.  wrote:

>
>
> On 25 September 2015 at 15:40, Chris Hoge  wrote:
>
>> In November, the OpenStack Foundation will start requiring vendors
>> requesting
>> new "OpenStack Compatible" storage driver licenses to start passing the
>> Cinder
>> third-party integration tests.
>
> The new program was approved by the Board at
>> the July meeting in Austin and follows the improvement of the testing
>> standards
>> and technical requirements for the "OpenStack Powered" program. This is
>> all
>> part of the effort of the Foundation to use the OpenStack brand to
>> guarantee a
>> base-level of interoperability and consistency for OpenStack users and to
>> protect the work of our community of developers by applying a trademark
>> backed
>> by their technical efforts.
>>
>> The Cinder driver testing is the first step of a larger effort to apply
>> community determined standards to the Foundation marketing programs. We're
>> starting with Cinder because it has a successful testing program in
>> place, and
>> we have plans to extend the program to network drivers and OpenStack
>> applications. We're going require CI testing for new "OpenStack
>> Compatible"
>> storage licenses starting on November 1, and plan to roll out network and
>> application testing in 2016.
>>
>> One of our goals is to work with project leaders and developers to help us
>> define and implement these test programs. The standards for third-party
>> drivers and applications should be determined by the developers and users
>> in our community, who are experts in how to maintain the quality of the
>> ecosystem.
>>
>> We welcome and feedback on this program, and are also happy to answer any
>> questions you might have.
>>
>
> Thanks for spearheading this effort.
>
> Do you have more information/pointers about the program, and how Cinder in
> particular is
> paving the way for other projects to follow?
>
> Thanks,
> Armando
>
>
>> Thanks!
>>
>> Chris Hoge
>> Interop Engineer
>> OpenStack Foundation
>> __
>> 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] [Ironic] Preparing for functional testing in Ironic. Will likely break any in-flight patches.

[Jim Rollenhagen]

On Mon, Sep 28, 2015 at 09:00:07PM +, Villalovos, John L wrote:
> Just to give a heads up to people. I have proposed the following patch:
> https://review.openstack.org/228612
> 
> This moves the tests in ironic/tests/ to ironic/tests/unit/
> 
> Likely this patch will break most in-flight patches, so rebasing will be 
> required when this patch goes in.

More concretely, the team wants to land this patch ASAP. It's the
beginning of the cycle, so presumably there aren't any patches we're
trying to get in quickly. We want to get it done before any more patches
sneak in new files/imports that break this.

I hope to land this today; if we don't, I plan to leave it with my +2
tonight and Dmitry can land it first thing in the morning. ;)

// jim

__
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] [fuel][ptl] PTL candidacy

[Sergii Golovatiuk]

Hi friends,


I’d like to raise my hand to send my candidacy for Fuel PTL position for
next cycle.

Before I go forward with my candidacy, I will remind some facts we’ve been
focuses as a team for last six months:

- Synchronisation with upstream modules. As a result we have a nice
mechanist to synchronise upstream manifests

- Plugin system improvements. We extended our plugin system to allow to
detach components. These changes creates a flexible mechanism for plugin
developers.

- HA Improvements. Fuel team polished OCF scripts. QA engineers automated a
lot of scenarios of our high availability architecture.

- Breaking Fuel to components. fuel-qa, fuel-agent and other components
were moved to own repositories. That increased the velocity of component
development.

- Fuel repositories. Fuel team implemented online repositories for
distribution system it supports. This allowed to speed up the update
delivery.

- Granular deployment. Instead of single ‘puppet apply’ fuel has a lot of
small applies. This step speed up the development process as the developer
doesn’t need to wait for whole deployment. He may apply only ‘required’
task. This flexibility gives a lot of room for plugin developers.


I believe there are some of the most important topics that our team should
focus on:

With my deployer/operator hat on:


- Continue breaking Fuel monolith to components. This will allow to
increase the velocity of product development. A good candidate is fuel-web.
There are some other projects that can be moved to own repositories.

- Switching to fuel2 CLI. We should finally deprecate first version of CLI.
fuel2 which is based on cliff should be a main tool for operator.

- Implement integration testing. Fuel is suffering from lack of integration
testing. This means that state of processes are not ensured after
deployment. Also, I am going to spend time to introduce code coverage
metrics that will be used for analysing if coverage is getting better or
not.

- CI improvements. Fuel is suffering from slow gates. ISO compilation,
master node deployment, openstack deployment require more and more time.
Reducing CI time will speed up the development process. I believe we should
start with metrics so we’ll know how much time is required from code to
deployed openstack. So, we’ll iteratively improve the bottle necks. In the
end, Developer will require less time for CI.

- Improve collaboration with Puppet OpenStack community. This part was
started as simple synchronisation of community manifests. A couple of
cycles we contributed a lot of bug fixes. In the end, Fuel team implemented
a nice mechanism that allows us to consume openstack-puppet modules without
any modifications. However, we are still in process of migration. It should
be done within next 6 months.

- Documentation improvements. I believe that documentation improvement will
allow to minimise the barrier for new contributors. I am going to add more
samples and details to our development documentation. A good sample is
puppetlabs-stdlib [1]

[1] https://github.com/puppetlabs/puppetlabs-stdlib

>From other hand, Fuelers have a lot of knowledge in OpenStack which should
be contributed back to upstream. I believe HA experience should contributed
back to upstream.

- Lifecycle improvements. I am going to make a paradigm shift that Fuel is
not only deployment tool. It’s very useful for lifecycle management.

With my leader hat on:

- Implementing lieutenant based model. Fuel Core developers are overloaded
with reviews. Switching to lieutenant model should free up their time that
can be spent on some R [2]

[2]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg62229.html

- The last but not least. I’ll do all my the best to get Fuel under Big
Tent.

I have many many things in my backlog. However, I believe the above are the
most important. I believe that resolving these issues will speed up the
velocity of development and make a cultural shift with many external
contributions.

Sincerely yours,

Sergii Golovatiuk
__
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] [nova][infra] Intel NFV CI, testing hugepages, numa topology, cpu pinning

[Znoinski, Waldemar]

Hi cores et al,

As discussed briefly with Jay Pipes in Vancouver, we were about to provide CI 
and tests for features such as: hugepages, cpu pinning, numa topology. We since 
worked on NFV CI here at Intel. The work on the CI and tests is now completed.

A few details about the CI and tests.
* CI WIKI [1]
* last issues with the tests[2] were resolved two weeks ago and the CI is 
stable since
* currently the CI is NOT commenting back to Gerrit
* changes and artifacts samples below[3]
* Intel NFV CI is based on the infrastructure used by Intel Networking CI [4] - 
see comments left by this CI for comment form and content


[1] https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-NFV-CI
[2] https://github.com/stackforge/intel-nfv-ci-tests
[3]
https://review.openstack.org/#/c/115484/ , 
http://intel-openstack-ci-logs.ovh/compute-ci/refs/changes/84/115484/28/
https://review.openstack.org/#/c/228168/ , 
http://intel-openstack-ci-logs.ovh/compute-ci/refs/changes/68/228168/2/
https://review.openstack.org/#/c/227138/ , 
http://intel-openstack-ci-logs.ovh/compute-ci/refs/changes/38/227138/3

[4] 
https://review.openstack.org/#/q/reviewer:%22Intel+Networking+CI+%253Copenstack-networking-ci%2540intel.com%253E%22,n,z

Unless there are  doubt and/or blockers we'd like to enable our CI commenting 
back with results and links to Nova in Openstack Gerrit.
All feedback welcome. I'll be attending Nova meeting this Thurs 1400 UTC for 
any follow ups as well.


Thanks
Waldek

--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

__
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] [all] Proposed Mitaka release schedule

[Thierry Carrez]

Hi everyone,

You can find the proposed release schedule for Mitaka here:

https://wiki.openstack.org/wiki/Mitaka_Release_Schedule

That places the end release on April 7, 2016. It's also worth noting
that in an effort to maximize development time, this schedule reduces
the time between Feature Freeze and final release by one week (5 weeks
instead of 6 weeks). That means we'll collectively have to be a lot
stricter on Feature freeze exceptions this time around. Be prepared for
that.

Feel free to ping the Release management team members on
#openstack-relmgr-office if you have any question.

-- 
Thierry Carrez (ttx)

__
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] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting this week. The meeting is being held
Tuesday UTC1200.

In other timezones the meeting is at:

EST 08:00 (Tue)
Japan 21:00 (Tue)
China 20:00 (Tue)
United Kingdom 13:00 (Tue)

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.
__
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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Sylvain Bauza]

Le 28/09/2015 16:19, Sean Dague a écrit :

On 09/28/2015 10:11 AM, Andrew Laski wrote:

On 09/28/15 at 08:50am, Monty Taylor wrote:

On 09/28/2015 07:58 AM, Sylvain Bauza wrote:



Specifically, I want "nova boot" to get me a VM with an IP address. I
don't want it to do fancy orchestration - I want it to not need fancy
orchestration, because needing fancy orchestration to get a VM  on a
network is not a feature.

In the networking case there is a minimum of orchestration because the
time required to allocate a port is small.  What has been requiring
orchestration is the creation of volumes because of the requirement of
Cinder to download an image, or be on a backend that support fast
cloning and rely on a cache hit.  So the question under discussion is
when booting an instance relies on another service performing a long
running operation where is a good place to handle that.

My thinking for a while has been that we could use another API that
could manage those things.  And be the central place you're looking for
to pass a simple "nova boot" with whatever options are required so you
don't have to manage the complexities of calls to
Neutron/Cinder/Nova(current API).  What's become clear to me from this
thread is that people don't seem to oppose that idea, however they don't
want their users/clients to need to switch what API they're currently
using(Nova).

The right way to proceed with this idea seems to be to by evolving the
Nova API and potentially creating a split down the road.  And by split I
more mean architectural within Nova, and not necessarily a split API.
What I imagine is that we follow the model of git and have a plumbing
and porcelain API and each can focus on doing the right things.

Right, and I think that's a fine approach. Nova's job is "give me a
working VM". Working includes networking, persistent storage. The API
semantics for "give me a working VM" should exist in Nova.

It is also fine if there are lower level calls that tweak parts of that,
but nova boot shouldn't have to be a multi step API process for the
user. Building one working VM you can do something with is really the
entire point of Nova.


I'm all for a request with some network and volume semantics in it, 
which would imply that the Nova scheduler would be able to do some 
instance placement based on cross-project resources.


What is a grey line to me is the fact that "give me a volume-backed 
instance from this image" requires some volume creation to get it done. 
So, if we consider that Nova is the best API for it (and I can 
understand the motivation for it), then we need some clear architectural 
segmentation between Nova and the other projects in Nova, like Andrew 
said (sorry if you feel I'm paraphrasing). For example, the move to 
os-brick is one of the efforts we should do, but it's just one step, 
since we should decouple all the tasks involved in the instance creation 
to isolate those in a better way).


-Sylvain


-Sean




__
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] [murano] Murano code flow for custom development and combining murano with horizon in devstack

[Sumanth Sathyanarayana]

Thanks Kirill.

Would adding "[murano]” to the subject line suffice or pls let me know if
there is a separate mailing list for murano?

Let me try to clarify what I am asking over here.
So we have all these panels - 'Compute', 'Network', etc on Horizon
dashboard.
If I add another panel like 'Example1' in Horizon by changing the code of
openstack-dashboard inside horizon, it gets added. Similarly if I change
the code of murano-dashboard and add another panel 'Example2' it gets added
as a separate panel. Now, assuming I have some changes in Horizon's
openstack-dashboard(i.e. example 1) and some changes in
murano-dashboard(i.e. example2) is there a way of combining them into one
panel i.e. say along with Compute, Network, etc panels I have something
like a Murano panel under which both the changes of Horizon's
openstack-dashboard(example1 - subpanel) and murano-dashboard(example2 -
subpanel) be incorporated.

Would a simple copy paste of say all the changes in Horizon's
openstack-dashboard to murano-dashboard work or is there a better way of
handling it.  Is murano-dashboard and openstack-dashboard code flow similar
with all the different files like 'tables.py', 'form.py', 'views.py', etc?
Does murano have a tutorial page something similar to this -
http://docs.openstack.org/developer/horizon/topics/tutorial.html

Thanks & Best Regards
Sumanth

On Mon, Sep 28, 2015 at 3:56 AM, Kirill Zaitsev 
wrote:

> Hi, murano-dashboard works the same way any other horizon dashboard does.
>
> I’m not quite sure, what you meant by «combined and showed under one tab»,
> could you please elaborate?
> If you’re asking about debugging — you can install murano-dashboard
> locally and configure it to use remote cloud (i.e. devstack) as descried
> here
> http://murano.readthedocs.org/en/latest/install/manual.html#install-murano-dashboard
>  .
> If not — then I did’t quite understood what you asked in the first place =)
>
> Feel free to come and ask around in #murano — you might get help there
> faster then on ML =)
>
> --
> Kirill Zaitsev
> Murano team
> Software Engineer
> Mirantis, Inc
>
> On 26 Sep 2015 at 02:24:10, Sumanth Sathyanarayana (
> sumanth.sathyanaray...@gmail.com) wrote:
>
> Hello,
>
> Could anyone let me know if the changes in murano dashboard and horizon's
> openstackdashboard, both be combined and showed under one tab.
> i.e. say under Murano tab on the side left panel all the changes done in
> horizon and murano both appear.
>
> If anyone could point me to a link explaining custom development of murano
> and the code flow would be very helpful...
>
> Thanks & Best Regards
> Sumanth
>
> __
> 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] [murano] Murano code flow for custom development and combining murano with horizon in devstack

[Kirill Zaitsev]

Hi

1) adding [murano] would definitely suffice

2) Seems that you want to combine some of the murano panels under your own 
dashboard, right? (I do not really see why would you want to do that, but 
still). I believe that it is possible. You can look at 
muranodashboard/dashboard.py file. It defines Panels and a Dashboard murano 
has. Technically you can import those and just follow instructions on 
http://docs.openstack.org/developer/horizon/topics/tutorial.html you mentioned. 

3) Murano-dashboard does not have such a page, because murano-dashboard is 
itself a dashboard built for horizon and follows the structure, defined in the 
article you mentioned.

I might have gotten something wrong, so I once again invite you to join #murano 
on freenode IRC. Would probably be much faster to chat there.

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 28 Sep 2015 at 18:23:41, Sumanth Sathyanarayana 
(sumanth.sathyanaray...@gmail.com) wrote:

Thanks Kirill.

Would adding "[murano]” to the subject line suffice or pls let me know if there 
is a separate mailing list for murano?

Let me try to clarify what I am asking over here.
So we have all these panels - 'Compute', 'Network', etc on Horizon dashboard.
If I add another panel like 'Example1' in Horizon by changing the code of 
openstack-dashboard inside horizon, it gets added. Similarly if I change the 
code of murano-dashboard and add another panel 'Example2' it gets added as a 
separate panel. Now, assuming I have some changes in Horizon's 
openstack-dashboard(i.e. example 1) and some changes in murano-dashboard(i.e. 
example2) is there a way of combining them into one panel i.e. say along with 
Compute, Network, etc panels I have something like a Murano panel under which 
both the changes of Horizon's openstack-dashboard(example1 - subpanel) and 
murano-dashboard(example2 - subpanel) be incorporated. 

Would a simple copy paste of say all the changes in Horizon's 
openstack-dashboard to murano-dashboard work or is there a better way of 
handling it.  Is murano-dashboard and openstack-dashboard code flow similar 
with all the different files like 'tables.py', 'form.py', 'views.py', etc? Does 
murano have a tutorial page something similar to this - 
http://docs.openstack.org/developer/horizon/topics/tutorial.html

Thanks & Best Regards
Sumanth

On Mon, Sep 28, 2015 at 3:56 AM, Kirill Zaitsev  wrote:
Hi, murano-dashboard works the same way any other horizon dashboard does.

I’m not quite sure, what you meant by «combined and showed under one tab», 
could you please elaborate?
If you’re asking about debugging — you can install murano-dashboard locally and 
configure it to use remote cloud (i.e. devstack) as descried here 
http://murano.readthedocs.org/en/latest/install/manual.html#install-murano-dashboard
 . If not — then I did’t quite understood what you asked in the first place =)

Feel free to come and ask around in #murano — you might get help there faster 
then on ML =)  

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 26 Sep 2015 at 02:24:10, Sumanth Sathyanarayana 
(sumanth.sathyanaray...@gmail.com) wrote:

Hello,

Could anyone let me know if the changes in murano dashboard and horizon's 
openstackdashboard, both be combined and showed under one tab.
i.e. say under Murano tab on the side left panel all the changes done in 
horizon and murano both appear.

If anyone could point me to a link explaining custom development of murano and 
the code flow would be very helpful...

Thanks & Best Regards
Sumanth

__
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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Andrew Laski]

On 09/28/15 at 10:19am, Sean Dague wrote:

On 09/28/2015 10:11 AM, Andrew Laski wrote:

On 09/28/15 at 08:50am, Monty Taylor wrote:

On 09/28/2015 07:58 AM, Sylvain Bauza wrote:




Specifically, I want "nova boot" to get me a VM with an IP address. I
don't want it to do fancy orchestration - I want it to not need fancy
orchestration, because needing fancy orchestration to get a VM  on a
network is not a feature.


In the networking case there is a minimum of orchestration because the
time required to allocate a port is small.  What has been requiring
orchestration is the creation of volumes because of the requirement of
Cinder to download an image, or be on a backend that support fast
cloning and rely on a cache hit.  So the question under discussion is
when booting an instance relies on another service performing a long
running operation where is a good place to handle that.

My thinking for a while has been that we could use another API that
could manage those things.  And be the central place you're looking for
to pass a simple "nova boot" with whatever options are required so you
don't have to manage the complexities of calls to
Neutron/Cinder/Nova(current API).  What's become clear to me from this
thread is that people don't seem to oppose that idea, however they don't
want their users/clients to need to switch what API they're currently
using(Nova).

The right way to proceed with this idea seems to be to by evolving the
Nova API and potentially creating a split down the road.  And by split I
more mean architectural within Nova, and not necessarily a split API.
What I imagine is that we follow the model of git and have a plumbing
and porcelain API and each can focus on doing the right things.


Right, and I think that's a fine approach. Nova's job is "give me a
working VM". Working includes networking, persistent storage. The API
semantics for "give me a working VM" should exist in Nova.

It is also fine if there are lower level calls that tweak parts of that,
but nova boot shouldn't have to be a multi step API process for the
user. Building one working VM you can do something with is really the
entire point of Nova.


What I'm struggling with is where do we draw the line in this model?  
For instance we don't allow a user to boot an instance from a disk image 
on their local machine via the Nova API, that is a multi step process.  
And which parameters do we expose that can influence network and volume 
creation, if not all of them?  It would be helpful to establish 
guidelines on what is a good candidate for inclusion in Nova.


I see a clear line between something that handles the creation of all 
ancillary resources needed to boot a VM and then the creation of the VM 
itself.  I don't understand why the creation of the other resources 
should live within Nova but as long as we can get to a good split 
between responsibilities that's a secondary concern.




-Sean

--
Sean Dague
http://dague.net

__
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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[masoom alam]

This is even not working:

root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack/accrc/admin#
neutron port-update e5b05961-e5d0-481b-bbd0-2ce4bbd9ea64
 --allowed-address-pairs type=list [] action=clear
AllowedAddressPair must contain ip_address


root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack/accrc/admin#
neutron port-update e5b05961-e5d0-481b-bbd0-2ce4bbd9ea64
 --allowed-address-pairs type=list {} action=clear
AllowedAddressPair must contain ip_address




On Mon, Sep 28, 2015 at 4:31 AM, masoom alam 
wrote:

> Please help, its not working:
>
> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
> port-show 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>
> +---+-+
> | Field | Value
> |
>
> +---+-+
> | admin_state_up| True
>|
> | allowed_address_pairs | {"ip_address": "10.0.0.201", "mac_address":
> "fa:16:3e:69:e9:ef"}|
> | binding:host_id   | openstack-latest-kilo-28-09-2015-masoom
> |
> | binding:profile   | {}
>|
> | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
>|
> | binding:vif_type  | ovs
> |
> | binding:vnic_type | normal
>|
> | device_id | d44b9025-f12b-4f85-8b7b-57cc1138acdd
>|
> | device_owner  | compute:nova
>|
> | extra_dhcp_opts   |
> |
> | fixed_ips | {"subnet_id":
> "bbb6726a-937f-4e0d-8ac2-f82f84272b1f", "ip_address": "10.0.0.3"} |
> | id| 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>|
> | mac_address   | fa:16:3e:69:e9:ef
> |
> | name  |
> |
> | network_id| ae1b7e34-9f6c-4c8f-bf08-99a1e390034c
>|
> | security_groups   | 8adda6d7-1b3e-4047-a130-a57609a0bd68
>|
> | status| ACTIVE
>|
> | tenant_id | 09945e673b7a4ab183afb166735b4fa7
>|
>
> +---+-+
>
> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
> port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9  --allowed-address-pairs
> [] action=clear
> AllowedAddressPair must contain ip_address
>
>
> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
> port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9  --allowed-address-pairs
> [10.0.0.201] action=clear
> The number of allowed address pair exceeds the maximum 10.
>
> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
> port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9  --allowed-address-pairs
>  action=clear
> Request Failed: internal server error while processing your request.
>
>
>
>
> On Mon, Sep 28, 2015 at 1:57 AM, Akihiro Motoki  wrote:
>
>> As already mentioned, we need to pass [] (an empty list) rather than None
>> as allowed_address_pairs.
>>
>> At the moment it is not supported in Neutron CLI.
>> This review https://review.openstack.org/#/c/218551/ is trying to fix
>> this problem.
>>
>> Akihiro
>>
>>
>> 2015-09-28 15:51 GMT+09:00 shihanzhang :
>>
>>> I don't see any exception using bellow command
>>>
>>> root@szxbz:/opt/stack/neutron# neutron port-update
>>> 3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
>>> Allowed address pairs must be a list.
>>>
>>>
>>>
>>> At 2015-09-28 14:36:44, "masoom alam"  wrote:
>>>
>>> stable KILO
>>>
>>> shall I checkout the latest code are you saying this...Also can you
>>> please confirm if you have tested this thing at your endand there was
>>> no problem...
>>>
>>>
>>> Thanks
>>>
>>> On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang 
>>> wrote:
>>>
 which branch do you use?  there is not this problem in master branch.





 At 2015-09-28 13:43:05, "masoom alam" 
 wrote:

 Can anybody highlight why the following command is throwing an
 exception:

 *Command#* neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3
 --allowed-address-pairs action=clear

 *Error: * 2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource
 [req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed

Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Mike Spreitzer]

> From: Monty Taylor 
> To: Sylvain Bauza , "OpenStack Development 
> Mailing List (not for usage questions)" 

> Date: 09/28/2015 09:54 AM
> Subject: Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how
> to handle AZ bug 1496235?)
>
> ...
> Specifically, I want "nova boot" to get me a VM with an IP address. I 
> don't want it to do fancy orchestration - I want it to not need fancy 
> orchestration, because needing fancy orchestration to get a VM  on a 
> network is not a feature.
> 
> I also VERY MUCH do not want to need Heat to get a VM. I want to use 
> Heat to do something complex. Getting a VM is not complex. It should not 

> be complex. What it's complex and to the level of needing Heat, we've 
> failed somewhere else.
> 
> Also, people should stop deploying clouds that require people to use 
> floating IPs to get basic internet access. It's a misuse of the 
construct.
> 
> Public Network "ext-net" -> shared / directly attachable
> Per-tenant Network "private" -> private network, not shared, not 
routable
> 
> If the user chooses, a router can be added with gateway set to ext-net.
> 
> This way:
> 
> nova boot --network=ext-net  -> vm dhcp'd on the public network
> nova boot --network=private  -> vm dhcp'd on the private network
> nova floating-ip-attach  -> vm gets a floating ip attached to their 
> vm from the ext-net network
> 
> All of the use cases are handled, basic things are easy (boot a vm on 
> the network works in one step) and for the 5% of cases where a floating 
> IP is actually needed (a long-lived service on a single vm that wants to 

> keep the IP and not just a DNS name across VM migrations and isn't using 

> a load-balancer) can use that.
> 
> This is, btw, the most common public cloud deployment model.
> 
> Let's stop making things harder than they need to be and serve our 
users.

As an operator, +1

Mike



__
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] Proposed Mitaka release schedule

[Ivan Kolodyazhny]

Hi Thierry,

Thank you for sharing this information with us so early. One
comment/question from me about FinalClientLibraryRelease:

Could we make client release at least one week later after M-3 milestone?
It will give us more chances to have features landed into the client if
they were merged late before M-3 and feature freeze.

Regards,
Ivan Kolodyazhny

On Mon, Sep 28, 2015 at 5:08 PM, Thierry Carrez 
wrote:

> Hi everyone,
>
> You can find the proposed release schedule for Mitaka here:
>
> https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
>
> That places the end release on April 7, 2016. It's also worth noting
> that in an effort to maximize development time, this schedule reduces
> the time between Feature Freeze and final release by one week (5 weeks
> instead of 6 weeks). That means we'll collectively have to be a lot
> stricter on Feature freeze exceptions this time around. Be prepared for
> that.
>
> Feel free to ping the Release management team members on
> #openstack-relmgr-office if you have any question.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [puppet] Moving puppet-ceph to the Openstack big tent

[David Moreau Simard]

Hi,

puppet-ceph currently lives in stackforge [1] which is being retired
[2]. puppet-ceph is also mirrored on the Ceph Github organization [3].
This version of the puppet-ceph module was created from scratch and
not as a fork of the (then) upstream puppet-ceph by Enovance [4].
Today, the version by Enovance is no longer officially maintained
since Red Hat has adopted the new release.

Being an Openstack project under Stackforge or Openstack brings a lot
of benefits but it's not black and white, there are cons too.

It provides us with the tools, the processes and the frameworks to
review and test each contribution to ensure we ship a module that is
stable and is held to the highest standards.
But it also means that:
- We forego some level of ownership back to the Openstack foundation,
it's technical committee and the Puppet Openstack PTL.
- puppet-ceph contributors will also be required to sign the
Contributors License Agreement and jump through the Gerrit hoops [5]
which can make contributing to the project harder.

We have put tremendous efforts into creating a quality module and as
such it was the first puppet module in the stackforge organization to
implement not only unit tests but also integration tests with third
party CI.
Integration testing for other puppet modules are just now starting to
take shape by using the Openstack CI inrastructure.

In the context of Openstack, RDO already ships with a mean to install
Ceph with this very module and Fuel will be adopting it soon as well.
This means the module will benefit from real world experience and
improvements by the Openstack community and packagers.
This will help further reinforce that not only Ceph is the best
unified storage solution for Openstack but that we have means to
deploy it in the real world easily.

We all know that Ceph is also deployed outside of this context and
this is why the core reviewers make sure that contributions remain
generic and usable outside of this use case.

Today, the core members of the project discussed whether or not we
should move puppet-ceph to the Openstack big tent and we had a
consensus approving the move.
We would also like to hear the thoughts of the community on this topic.

Please let us know what you think.

Thanks,

[1]: https://github.com/stackforge/puppet-ceph
[2]: https://review.openstack.org/#/c/192016/
[3]: https://github.com/ceph/puppet-ceph
[4]: https://github.com/redhat-cip/puppet-ceph
[5]: https://wiki.openstack.org/wiki/How_To_Contribute

David Moreau Simard

__
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] [election][tc] TC Candidacy

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Greetings Stackers! I'm announcing my candidacy for the Technical
Committee Elections.

Those of you who have been involved in OpenStack most likely know me,
as I was part of the original team from Rackspace that created
OpenStack in 2010. For the past year or so I have been employed at IBM
to work on 100% upstream OpenStack development. Part of that time has
been spent getting a good overview of both the project and the
community behind it. I've also placed some of my focus on the groups
of people working *with* OpenStack, and not just those developing it.
And to that end I've been working with the current TC as much as
possible, especially in the areas of API standardization and
consistency. I'm always lurking on the regular TC meetings (and
sometimes throwing in my two cents), and reviewing as much of the
material as I can. I believe that I can have a much greater impact as
part of the TC instead of just being that occasional voice from the
back of the room.

There are some good reasons not to vote for me: the other TC
candidates. I wish I could run on a "throw out the bums" platform, but
that's simply not possible.  I know all the current members, and they
have all done an excellent job this past year, and would all represent
the community well if re-elected. I can only promise that if elected,
I will work hard to have at least as much positive impact on the
community as the TC member I might replace. That will be a difficult
task indeed, but I believe that I have the long-term experience to
help guide OpenStack as it continues to grow and thrive in the future.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWCWEfAAoJEKMgtcocwZqLTJIP/2K4pD+jhdDO487k5zLUlYvY
8NB6Zv7VG7i6LRllX6D8M9zKgG2/vEknHa76lgE23N1fjhnSJ9zLyffLyAPmmOvT
T0Z4U80as8sxZCq7RwWvLh0VvyLq/wlXr1bHkTHiZbQTZl4B/V2fvVWATktkrf9T
Pv4BgVJTQj/lkLN6RVz027/z6t8bGx9idGYsU6BI3mQifO1ebePWxhPtr5BvZG+P
Bnio7Ya4cQqX9KPWNge6chlRCWZ8vsdCqxP5jJz4O7GTbXJPJ2X1WVHJZNpLq0Q+
+tvN1vKkdFbfQWFCQLUVyk0+qoE+SmGxksB7I77PK4sw49Yw8TZjXimQoDWyM1+x
6WlVleDvBQeHXB+13jjlJNkHIXb1typ28+nb9yU5pummH4OiTs/uVsqxqwZCAIOd
WwDDKoj2x17RsSbluVgQn7yAHE/5e82/HlZnBDKrtkQpc1qyNdq755zMbY8qLJk+
xH+qGvw//kicSFsERNZNX8JC0z8suVovuC+T7ZAyOZ9obk0LkT9+9E7BfnRxK0mi
URG9iyoZ02u4csN+hQz59+LrBLq+TqFga4pX3zqYQbCH+yXvEJg1iwHWbso3ERUn
uR1r2IBj8p6ZTh+iGzc7/7yyu/mpHV+FDjtOwA0GtBDOqvF0k83Vn1KDI0hvdzzx
JpjI9XunME417m8904qJ
=Q8LE
-END PGP SIGNATURE-

__
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] [Infra] Meeting Tuesday September 29th at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday September 29th[0], at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full logs from our last couple of meetings are available.

September 15th:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-15-19.02.log.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-15-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-15-19.02.log.html

September 22nd:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-22-19.02.log.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-22-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-09-22-19.02.log.html

[0] The 29th is also my birthday, I accept presents in the form of
cute cat pictures, but let's save those until after the meeting ;)

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Ryan Brown]

On 09/26/2015 12:04 AM, Joshua Harlow wrote:

+1 from me, although I thought heat was supposed to be this thing?

Maybe there should be a 'warm' project or something ;)

Or we can call it 'bbs' for 'building block service' (obviously not
bulletin board system); ask said service to build a set of blocks into
well defined structures and let it figure out how to make that happen...

This though most definitely requires cross-project agreement though so
I'd hope we can reach that somehow (before creating a halfway done new
orchestration thing that is halfway integrated with a bunch of other
apis that do one quarter of the work in ten different ways).


Indeed, I don't think I understand what need heat is failing to fulfill 
here? A user can easily have a template that contains a single server 
and a volume.


Heat's job is to be an API that lets you define a result[1] and then 
calls the APIs of whatever projects provide those things.


1: in this case, the result is "a working server with network and storage"


Duncan Thomas wrote:

I think there's a place for yet another service breakout from nova -
some sort of like-weight platform orchestration piece, nothing as
complicated or complete as heat, nothing that touches the inside of a
VM, just something that can talk to cinder, nova and neutron (plus I
guess ironic and whatever the container thing is called) and work
through long running / cross-project tasks. I'd probably expect it to
provide a task style interface, e.g. a boot-from-new-volume call returns
a request-id that can then be polled for detailed status.

The existing nova API for this (and any other nova APIs where this makes
sense) can then become a proxy for the new service, so that tenants are
not affected. The nova apis can then be deprecated in slow time.

Anybody else think this could be useful?


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
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] [Barbican][Security] Automatic Certificate Management Environment

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Rob,

I agree that the ACME standard is very interesting, but I'm also
pretty new to it.  And by pretty new I mean I just started reading it
after I saw your email. :)

There has been interest in adding support for Let's Encrypt as a
Barbican back end since it was first announced, but I don't think
anyone has looked into it recently.

Being able to deploy Barbican and issue free certificates via Let's
Encrypt is a very compelling feature, but it's definitely going to
take some effort to figure out the best way to do it.  The first issue
that I can see is sorting out auth.  The Public CA plugins we're
developing all work under the assumption that Barbican itself is a
client to the CA and has a set of credentials that can be used to
interact with it.

The Let's Encrypt model is different in that Barbican itself probably
does not want to have a set of credentials to to talk to Let's
Encrypt, or we would end up owning all of our client's certs.  So
we'll have to figure out a way for clients to be able to provide their
Let's Encrypt credentials to Barbican.

Another challenge is going to be sorting out the automated domain
verification.  We could possibly just proxy the challenges to the
client and then wait for the client to let us know which verification
challenges have been completed.

As far as supporting ACME on the front end, I'm not sure it would be
possible.  There is a lot of overlap between ACME and the current
Barbican CMS API.  Adding support for ACME would basically mean
supporting two competing APIs in a single product, which is sure to
cause confusion and a ton of overhead in development.

Additionally, there are features in ACME that I think would prove
almost impossible to support with existing public CAs.  Namely the
automated challenge feature.  Currently Barbican CMS defers the Domain
Validation to some out-of-band process between the CA and the client.
 So you could, for example, order a Symantec Cert using the Barbican
API.  Barbican would begin the Cert workflow in an automated fashion,
but at some point someone from Symantec is going to email the domain
owner and they're going to have to respond to the challenges the good
old fashioned way.

I think that a prerequisite for ACME support on the front end is going
to be Public CA support of the ACME standard.  At that point we could
probably phase out the Barbican CMS API, and just support ACME on the
front end.

- - Douglas Mendizábal

On 9/24/15 10:12 AM, Clark, Robert Graham wrote:
> Hi All,
> 
> So I did a bit of tyre kicking with Letsencrypt today, one of the
> things I thought was interesting was the adherence to the
> burgeoning Automatic Certificate Management Environment (ACME)
> standard.
> 
> https://letsencrypt.github.io/acme-spec/
> 
> It’s one of the more readable crypto related standards drafts out
> there, reading it has me wondering how this might be useful for
> Anchor, or indeed for Barbican where things get quite interesting,
> both at the front end (enabling ACME clients to engage with
> Barbican) or at the back end (enabling Barbican to talk to any
> number of ACME enabled CA endpoints.
> 
> I was wondering if there’s been any discussion/review here, I’m new
> to ACME but I’m not sure if I’m late to the party…
> 
> Cheers -Rob
> 
> __

>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCVvsAAoJEB7Z2EQgmLX7eMUP/1qRXJJfmmQgI/z4rj13ug8q
IAG+iENDhhXojZyvf0F87zhj6DnQSTOzGwKIotP0FxUpLGSiNOYsKix4+OIShWqH
7HPdMLZnl6cROf/n11QgSQouvhRpUTW/UKtGaPGCO2Lw53LXHQqNOXCQdq12mdhT
CB9+55PpG7dr3bY9vX9PeB61QP410+c68ICcHhpOAFEm5TnmV0NL2JQ0zkjwENM3
s3kwIyZE3awZg3fp9zdxzuI87OEqQ+f4PN55q7GMJjwAdU72SU7crFjrpJxlPCCr
LuEb6J1rz9I5eThp2woaLOS1w4irBwrk5kp+0Af8Z2VZqWo2/mX6VlQJ5cgIMQdp
je3Ku500bQSjWAfv8/CJBIQ4bkBnOwaBWxzsXEzYDlHofQQHHubpsUlV202BOtIZ
F9BN0P/siwSQ+GOmCYd64AfAsBwjiY7uhOong50GFjThDkLxgRuOXjtt7u7ZBfvF
PbLRfo9teJju6zQHrE+G4WUURdBIP9NEDr7kkT7uDcVXNrPLY/8Op4tdws5yk49w
BFlWrjCZ8uuhDGm6gyaLzjcY/UU3Zwf8G4E4CL7YpWYLhVuaqs7ig/qbTUEK/xdt
+C6yU6JJGYT9j+H18sZOCMlvXRNG3W9CO/6fKiZ1PprsYXDN2UYfYHIyBNROeVkj
au8DQsYCyQBpkJStuJwt
=8g77
-END PGP SIGNATURE-

__
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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Andrew Laski]

On 09/28/15 at 08:50am, Monty Taylor wrote:

On 09/28/2015 07:58 AM, Sylvain Bauza wrote:



Le 28/09/2015 12:35, Duncan Thomas a écrit :



On 28 September 2015 at 12:35, Sylvain Bauza > wrote:

   About the maintenance burden, I also consider that patching
   clients is far more easier than patching an API unless I missed
   something.


I think I very much disagree there - patching a central installation
is much, much easier than getting N customers to patch M different
libraries, even assuming the fix is available for any significant
subset of the M libraries, plus making sure that new customers use the
correct libraries, plus helping any customers who have some sort of
roll-your-own library do the new right thing...



Well, having N versions of clients against one single API version is
just something we manage since the beginning. I don't really see why it
suddently becomes so difficult to manage it.



I think there's a definite place for a simple API to do infrastructure
level orchestration without needing the complexities of heat - these
APIs are in nova because they're useful - there's clear operator
desire for them and a couple of operators have been quite vocal about
their desire for them not to be removed. Great, let's keep them, but
form a team of people interested in getting them right (get rid of
fixed timeouts, etc), add any missing pieces (like floating IPs for
new VMs) and generally focus on getting this piece of the puzzle
right. Breaking another small piece off nova and polishing it has been
a generally successful pattern.


I don't want to overthink what could be the right scope of that future
API but given the Heat mission statement [1] and its service name
'orchestration', I don't see why this API endpoint should land in the
Nova codebase and couldn't be rather provided by the Heat API. Oh sure,
it would perhaps require another endpoint behind the same service, but
isn't that better than having another endpoint in Nova ?

[1]
https://github.com/openstack/governance/blob/master/reference/projects.yaml#L482-L484




I remember Monty Taylor (copied) having a rant about the lack of the
perfect 'give me a VM with all its stuff sorted' API. Care to comment,
Monty?


Sounds you misunderstood me. I'm not against implementing this excellent
usecase, I just think the best place is not in Nova and should be done
elsewhere.



Specifically, I want "nova boot" to get me a VM with an IP address. I 
don't want it to do fancy orchestration - I want it to not need fancy 
orchestration, because needing fancy orchestration to get a VM  on a 
network is not a feature.


In the networking case there is a minimum of orchestration because the 
time required to allocate a port is small.  What has been requiring 
orchestration is the creation of volumes because of the requirement of 
Cinder to download an image, or be on a backend that support fast 
cloning and rely on a cache hit.  So the question under discussion is 
when booting an instance relies on another service performing a long 
running operation where is a good place to handle that.


My thinking for a while has been that we could use another API that 
could manage those things.  And be the central place you're looking for 
to pass a simple "nova boot" with whatever options are required so you 
don't have to manage the complexities of calls to 
Neutron/Cinder/Nova(current API).  What's become clear to me from this 
thread is that people don't seem to oppose that idea, however they don't 
want their users/clients to need to switch what API they're currently 
using(Nova).


The right way to proceed with this idea seems to be to by evolving the 
Nova API and potentially creating a split down the road.  And by split I 
more mean architectural within Nova, and not necessarily a split API.  
What I imagine is that we follow the model of git and have a plumbing 
and porcelain API and each can focus on doing the right things.





I also VERY MUCH do not want to need Heat to get a VM. I want to use 
Heat to do something complex. Getting a VM is not complex. It should 
not be complex. What it's complex and to the level of needing Heat, 
we've failed somewhere else.


Also, people should stop deploying clouds that require people to use 
floating IPs to get basic internet access. It's a misuse of the 
construct.


Public Network "ext-net" -> shared / directly attachable
Per-tenant Network "private" -> private network, not shared, not routable

If the user chooses, a router can be added with gateway set to ext-net.

This way:

nova boot --network=ext-net  -> vm dhcp'd on the public network
nova boot --network=private  -> vm dhcp'd on the private network
nova floating-ip-attach  -> vm gets a floating ip attached to 
their vm from the ext-net network


All of the use cases are handled, basic things are easy (boot a vm on 
the network works in one step) and for the 5% of cases where a 
floating IP is actually 

Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Sean Dague]

On 09/28/2015 10:11 AM, Andrew Laski wrote:
> On 09/28/15 at 08:50am, Monty Taylor wrote:
>> On 09/28/2015 07:58 AM, Sylvain Bauza wrote:

>>
>> Specifically, I want "nova boot" to get me a VM with an IP address. I
>> don't want it to do fancy orchestration - I want it to not need fancy
>> orchestration, because needing fancy orchestration to get a VM  on a
>> network is not a feature.
> 
> In the networking case there is a minimum of orchestration because the
> time required to allocate a port is small.  What has been requiring
> orchestration is the creation of volumes because of the requirement of
> Cinder to download an image, or be on a backend that support fast
> cloning and rely on a cache hit.  So the question under discussion is
> when booting an instance relies on another service performing a long
> running operation where is a good place to handle that.
> 
> My thinking for a while has been that we could use another API that
> could manage those things.  And be the central place you're looking for
> to pass a simple "nova boot" with whatever options are required so you
> don't have to manage the complexities of calls to
> Neutron/Cinder/Nova(current API).  What's become clear to me from this
> thread is that people don't seem to oppose that idea, however they don't
> want their users/clients to need to switch what API they're currently
> using(Nova).
> 
> The right way to proceed with this idea seems to be to by evolving the
> Nova API and potentially creating a split down the road.  And by split I
> more mean architectural within Nova, and not necessarily a split API. 
> What I imagine is that we follow the model of git and have a plumbing
> and porcelain API and each can focus on doing the right things.

Right, and I think that's a fine approach. Nova's job is "give me a
working VM". Working includes networking, persistent storage. The API
semantics for "give me a working VM" should exist in Nova.

It is also fine if there are lower level calls that tweak parts of that,
but nova boot shouldn't have to be a multi step API process for the
user. Building one working VM you can do something with is really the
entire point of Nova.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [devstack] Is there a way to configure devstack for one flat external network using Kilo, Neutron?

[Mike Spreitzer]

Is there a way to configure devstack to install Neutron such that there is 
just one network and that is an external network and Nova can create 
Compute Instances on it, using projects of Kilo vintage?

Thanks,
Mike



__
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] [election] [tc] Candidacy for Technical Committee

[Anne Gentle]

Hi all,

I'm writing to let you know I would like to run for Technical Committee
again this term.

Here is my candidacy statement for your review.

I have worked at Rackspace on the OpenStack collection of projects for five
years now, working primarily on documentation. Rackspace is one of the
founding
organizations and currently running and supporting both public and private
clouds. I work on the developer experience team at Rackspace where we
advocate
for the cloud developer through support, tools, outreach in the community,
and
documentation.

In that time I've learned a lot about the people and projects that make up
OpenStack, and I've served the project in capacities that are often lacking
in
open source -- documentation, communication, API standards, and on-boarding
newcomers, especially under-represented groups such as women in technology.

The growth of OpenStack as a whole has been phenomenal. That growth and
attention has afforded us some experimentation with community, collaborative
documentation. In 2012 we assembled a team of operators to write the
OpenStack
Operations Guide that now is available as an O'Reilly book. We copied that
model successfully twice now with the Security Guide and the Architecture
and
Design Guide. Now project teams are completing focused documentation
efforts.
In 2014 the docs team implemented a new RST-based web design that makes the
docs.openstack.org site more usable and also easier to contribute to. In the
Kilo release we saw the highest number of docs contributors were for the
REST
API documentation. In the past six months I've been writing blog entries
with
fellow TC members in order to offer a line of communication beyond the
mailing
lists. This year my focus has been on API documentation and cross-project
work,
all the while supporting Docs PTL Lana Brindley in continuing the many
documentation efforts.

Why should I earn your vote? Vote for me if you care about cross-project
collaboration and communication especially. In the next year I want to find
innovative solutions to hard problems as OpenStack matures and continues to
strive for interoperability.

My expertise and experience in end-user support including useful and
consistent
REST APIs lends itself well to working on the Technical Committee. I have an
extensive network of relationships with both public and private cloud
experts
at Rackspace and beyond.

I am interested in the long-term viability of OpenStack as a whole. I
intend to
continue working hard for the community. I believe the Technical Committee
is
the best place for me to work with others to keep OpenStack on the right
track
to offering an open source cloud for the world.

Get to know me and my work:
OpenStack profile: https://www.openstack.org/community/members/profile/87
OpenStack blog: https://www.openstack.org/blog/author/annegentle/
Stackalytics: http://stackalytics.com/?user_id=annegentle
Reviews: https://review.openstack.org/#/q/reviewer:%22Anne+Gentle%22,n,z
Commits: https://review.openstack.org/#/q/owner:%22Anne+Gentle%22,n,z
IRC: annegentle
Blog: http://justwriteclick.com/
Candidate Statement: https://review.openstack.org/228482

Thanks for your consideration,
Anne

-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
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] [TripleO] tripleo.org theme

[Jeremy Stanley]

On 2015-09-28 09:43:37 -0400 (-0400), James Slagle wrote:
> Would the content of tripleo-docs be exactly the same as what is
> published at http://docs.openstack.org/developer/tripleo-docs/ ?
> 
> I think it probably should be, and be updated on every merged commit.
> If that's not the case, I think it should be abundantly clear why
> someone might would use one set of docs over the other.
[...]

If you're looking at Project Infrastructure/Upstream CI integration
with that site, I encourage you to just move remaining content to
docs.openstack.org or possibly implement rewrites to something like
tripleo.openstack.org. We've been doing the same for other "vanity"
domains (see recent moves of devstack.org, refstack.org,
trystack.org) so that we can get everything under a common base
domain unless there is an actual technical requirement to have a
separate domain (e.g. the cross-domain browser security concerns
which drove us to register openstackid.org for our OpenID
authentication).
-- 
Jeremy Stanley

__
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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[Akihiro Motoki]

Are you reading our reply comments?
At the moment, there is no way to set allowed-address-pairs to an empty
list by using neutron CLI.
When action=clear is passed, type=xxx, list=true and specified values are
ignored and None is sent to the server.
Thus you cannot set allowed-address-pairs to [] with neutron port-update
CLI command.


2015-09-28 22:54 GMT+09:00 masoom alam :

> This is even not working:
>
> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack/accrc/admin#
> neutron port-update e5b05961-e5d0-481b-bbd0-2ce4bbd9ea64
>  --allowed-address-pairs type=list [] action=clear
> AllowedAddressPair must contain ip_address
>
>
> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack/accrc/admin#
> neutron port-update e5b05961-e5d0-481b-bbd0-2ce4bbd9ea64
>  --allowed-address-pairs type=list {} action=clear
> AllowedAddressPair must contain ip_address
>
>
>
>
> On Mon, Sep 28, 2015 at 4:31 AM, masoom alam 
> wrote:
>
>> Please help, its not working:
>>
>> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack#
>> neutron port-show 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>>
>> +---+-+
>> | Field | Value
>> |
>>
>> +---+-+
>> | admin_state_up| True
>>  |
>> | allowed_address_pairs | {"ip_address": "10.0.0.201", "mac_address":
>> "fa:16:3e:69:e9:ef"}|
>> | binding:host_id   | openstack-latest-kilo-28-09-2015-masoom
>> |
>> | binding:profile   | {}
>>  |
>> | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
>>  |
>> | binding:vif_type  | ovs
>> |
>> | binding:vnic_type | normal
>>  |
>> | device_id | d44b9025-f12b-4f85-8b7b-57cc1138acdd
>>  |
>> | device_owner  | compute:nova
>>  |
>> | extra_dhcp_opts   |
>> |
>> | fixed_ips | {"subnet_id":
>> "bbb6726a-937f-4e0d-8ac2-f82f84272b1f", "ip_address": "10.0.0.3"} |
>> | id| 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>>  |
>> | mac_address   | fa:16:3e:69:e9:ef
>> |
>> | name  |
>> |
>> | network_id| ae1b7e34-9f6c-4c8f-bf08-99a1e390034c
>>  |
>> | security_groups   | 8adda6d7-1b3e-4047-a130-a57609a0bd68
>>  |
>> | status| ACTIVE
>>  |
>> | tenant_id | 09945e673b7a4ab183afb166735b4fa7
>>  |
>>
>> +---+-+
>>
>> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack#
>> neutron port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>>  --allowed-address-pairs [] action=clear
>> AllowedAddressPair must contain ip_address
>>
>>
>> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack#
>> neutron port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>>  --allowed-address-pairs [10.0.0.201] action=clear
>> The number of allowed address pair exceeds the maximum 10.
>>
>> root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack#
>> neutron port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
>>  --allowed-address-pairs  action=clear
>> Request Failed: internal server error while processing your request.
>>
>>
>>
>>
>> On Mon, Sep 28, 2015 at 1:57 AM, Akihiro Motoki 
>> wrote:
>>
>>> As already mentioned, we need to pass [] (an empty list) rather than
>>> None as allowed_address_pairs.
>>>
>>> At the moment it is not supported in Neutron CLI.
>>> This review https://review.openstack.org/#/c/218551/ is trying to fix
>>> this problem.
>>>
>>> Akihiro
>>>
>>>
>>> 2015-09-28 15:51 GMT+09:00 shihanzhang :
>>>
 I don't see any exception using bellow command

 root@szxbz:/opt/stack/neutron# neutron port-update
 3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
 Allowed address pairs must be a list.



 At 2015-09-28 14:36:44, "masoom alam" 
 wrote:

 stable KILO

 shall I checkout the latest code are you saying this...Also can you
 please confirm if you have tested this thing at your endand there was
 no problem...


 Thanks

 On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang 

[openstack-dev] [ceilometer] OpenStack Telemetry user survey

[gord chung]

Hello,

The OpenStack Telemetry (aka Ceilometer) team would like to collect 
feedback and information from its user base in order to drive future 
improvements to the project.  To do so, we have developed a survey. It 
should take about 15min to complete.
Questions are fairly technical, so please ensure that you ask someone 
within your organization that is hands on using Ceilometer.


https://goo.gl/rKNhM1

On behalf of the Ceilometer community, we thank you for the time you 
will spend in helping us understand your needs.


--
Gordon Chung
Ceilometer PTL

__
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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[masoom alam]

stable KILO

shall I checkout the latest code are you saying this...Also can you please
confirm if you have tested this thing at your endand there was no
problem...


Thanks

On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang  wrote:

> which branch do you use?  there is not this problem in master branch.
>
>
>
>
>
> At 2015-09-28 13:43:05, "masoom alam"  wrote:
>
> Can anybody highlight why the following command is throwing an exception:
>
> *Command#* neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3
> --allowed-address-pairs action=clear
>
> *Error: * 2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource
> [req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most
> recent call last):
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result =
> method(request=request, **args)
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
> allow_bulk=self._allow_bulk)
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/api/v2/base.py", line 652, in
> prepare_request_body
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
> attr_vals['validate'][rule])
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
> "/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in
> _validate_allowed_address_pairs
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if
> len(address_pairs) > cfg.CONF.max_allowed_address_pair:
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of
> type 'NoneType' has no len()
> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
>
>
>
> There is a similar bug filed at Lauchpad for Havana
> https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there
> is no fix and the work around  - using curl, mentioned on the bug is also
> not working for KILO...it was working for havana and Icehouseany
> pointers...?
>
> Thanks
>
>
>
>
> 网易考拉iPhone6s玫瑰金5288元，现货不加价
> 
>
> __
> 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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Sylvain Bauza]

Le 25/09/2015 16:12, Andrew Laski a écrit :

On 09/24/15 at 03:13pm, James Penick wrote:



At risk of getting too offtopic I think there's an alternate 
solution to
doing this in Nova or on the client side.  I think we're missing 
some sort

of OpenStack API and service that can handle this.  Nova is a low level
infrastructure API and service, it is not designed to handle these
orchestrations.  I haven't checked in on Heat in a while but perhaps 
this

is a role that it could fill.

I think that too many people consider Nova to be *the* OpenStack API 
when
considering instances/volumes/networking/images and that's not 
something I

would like to see continue.  Or at the very least I would like to see a
split between the orchestration/proxy pieces and the "manage my
VM/container/baremetal" bits



(new thread)
You've hit on one of my biggest issues right now: As far as many 
deployers

and consumers are concerned (and definitely what I tell my users within
Yahoo): The value of an OpenStack value-stream (compute, network, 
storage)

is to provide a single consistent API for abstracting and managing those
infrastructure resources.

Take networking: I can manage Firewalls, switches, IP selection, SDN, 
etc

through Neutron. But for compute, If I want VM I go through Nova, for
Baremetal I can -mostly- go through Nova, and for containers I would 
talk

to Magnum or use something like the nova docker driver.

This means that, by default, Nova -is- the closest thing to a top level
abstraction layer for compute. But if that is explicitly against Nova's
charter, and Nova isn't going to be the top level abstraction for all
things Compute, then something else needs to fill that space. When that
happens, all things common to compute provisioning should come out of 
Nova

and move into that new API. Availability zones, Quota, etc.


I do think Nova is the top level abstraction layer for compute. My 
issue is when Nova is asked to manage other resources.  There's no API 
call to tell Cinder "create a volume and attach it to this instance, 
and create that instance if it doesn't exist."  And I'm not sure why 
the reverse isn't true.


I want Nova to be the absolute best API for managing compute 
resources.  It's when someone is managing compute and volumes and 
networks together that I don't feel that Nova is the best place for 
that.  Most importantly right now it seems that not everyone is on the 
same page on this and I think it would be beneficial to come together 
and figure out what sort of workloads the Nova API is intending to 
provide.


I totally agree with you on those points :
 - nova API should be only supporting CRUD operations for compute VMs 
and should no longer manage neither volumes nor networks IMHO, because 
it creates more problems than it resolves
 - given the above, nova API could possibly accept resources from 
networks or volumes but only for placement decisions related to instances.


Tho, I can also understand that operators sometimes just want a single 
tool for creating this kind of relationship between a volume and an 
instance (and not provide a YAML file), but IMHO, it doesn't perhaps 
need a top-level API, just a python client able to do some very simple 
orchestration between services, something like openstack-client.


I don't really see a uber-value for getting a proxy API calling Nova or 
Neutron. IMHO, that should still be done by clients, not services.


-Sylvain





-James


__ 


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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[shihanzhang]

which branch do you use?  there is not this problem in master branch.





At 2015-09-28 13:43:05, "masoom alam"  wrote:

Can anybody highlight why the following command is throwing an exception:


Command# neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3 
--allowed-address-pairs action=clear


Error:  2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource 
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in 
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if len(address_pairs) 
> cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of type 
'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource






There is a similar bug filed at Lauchpad for Havana 
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is no 
fix and the work around  - using curl, mentioned on the bug is also not working 
for KILO...it was working for havana and Icehouseany pointers...?


Thanks



__
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] [Fuel][Plugins] add health check for plugins

[Samuel Bartel]

Hi,

Totally agree with you Andrey,
other use cases could be :
-for Ironic plugin, add test to validate that Ironic is properly deploy
-for LMA plugin check that metric and log are properly collect, that elk,
nagios or grafana dashboard are accessible
-for cinder netapp multi backend, check that different type of backend can
be crreated
and so on

So it would be very intersting to have enxtensibility ofr OSTF test


Samuel

2015-09-08 0:05 GMT+02:00 Andrey Danin :

> Hi.
>
> Sorry for bringing this thread back from the grave but it look quite
> interesting to me.
>
> Sheena, could you please explain how pre-deployment sanity checks should
> look like? I don't get what it is.
>
> From the Health Check point of view plugins may be divided to two groups:
>
> 1) A plugin that doesn't change an already covered functionality thus
> doesn't require extra tests implemented. Such plugins may be Contrail and
> almost all SDN plugins, Glance or Cinder backend plugins, and others which
> don't bring any changes in OSt API or any extra OSt components.
>
> 2) A plugin that adds new elements into OSt or changes API or a standard
> behavior. Such plugins may be Contrail (because it actually adds Contrail
> Controller which may be covered by Health Check too), Cisco ASR plugin
> (because it always creates HA routers), some Swift plugins (we don't have
> Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because
> they require special network preparation and extra drivers to be presented
> in an image), when a combination of different ML2 plugins or hypervisors
> deployed (because you need to test all network underlayers or HVs).
>
> So, all that means we need to make OSTF extendible by Fuel plugin's tests
> eventually.
>
>
> On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson 
> wrote:
>
>> I like that idea a lot – I also think there would be value in adding
>> pre-deployment sanity checks that could be called from the Health Check
>> screen prior to deployment.  Thoughts?
>>
>>
>>
>> *From:* Simon Pasquier [mailto:spasqu...@mirantis.com]
>> *Sent:* Monday, August 10, 2015 9:00 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for
>> plugins
>>
>>
>>
>> Hello Samuel,
>>
>> This looks like an interesting idea. Do you have any concrete example to
>> illustrate your point (with one of your plugins maybe)?
>>
>> BR,
>>
>> Simon
>>
>>
>>
>> On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel <
>> samuel.bartel@gmail.com> wrote:
>>
>> Hi all,
>>
>>
>>
>> actually with fuel plugins there are test for the plugins used by the
>> CICD, but after a deployment it is not possible for the user to easily test
>> if a plugin is crrectly deploy or not.
>>
>> I am wondering if it could be interesting to improve the fuel plugin
>> framework in order to be able to define test for each plugin which would ba
>> dded to the health Check. the user would be able to test the plugin when
>> testing the deployment test.
>>
>>
>>
>> What do you think about that?
>>
>>
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Samuel
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> 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] [oslo] nominating Brant Knudson for Oslo core

[Victor Stinner]

+1 for Brant

Victor

Le 24/09/2015 19:12, Doug Hellmann a écrit :

Oslo team,

I am nominating Brant Knudson for Oslo core.

As liaison from the Keystone team Brant has participated in meetings,
summit sessions, and other discussions at a level higher than some
of our own core team members.  He is already core on oslo.policy
and oslo.cache, and given his track record I am confident that he would
make a good addition to the team.

Please indicate your opinion by responding with +1/-1 as usual.

Doug

__
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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[shihanzhang]

I don't see any exception using bellow command


root@szxbz:/opt/stack/neutron# neutron port-update 
3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
Allowed address pairs must be a list.




At 2015-09-28 14:36:44, "masoom alam"  wrote:

stable KILO


shall I checkout the latest code are you saying this...Also can you please 
confirm if you have tested this thing at your endand there was no problem...




Thanks


On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang  wrote:

which branch do you use?  there is not this problem in master branch.






At 2015-09-28 13:43:05, "masoom alam"  wrote:

Can anybody highlight why the following command is throwing an exception:


Command# neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3 
--allowed-address-pairs action=clear


Error:  2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource 
[req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
allow_bulk=self._allow_bulk)
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 652, in prepare_request_body
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource 
attr_vals['validate'][rule])
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in 
_validate_allowed_address_pairs
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if len(address_pairs) 
> cfg.CONF.max_allowed_address_pair:
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object of type 
'NoneType' has no len()
2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource






There is a similar bug filed at Lauchpad for Havana 
https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there is no 
fix and the work around  - using curl, mentioned on the bug is also not working 
for KILO...it was working for havana and Icehouseany pointers...?


Thanks








网易考拉iPhone6s玫瑰金5288元，现货不加价


__
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] [murano] Outreachy: Interest in contributing to open-source

[Ekaterina Chernova]

Hi Yolande,

welcome to OpenStack and open source!

We gladly introduce you with Murano project!

Topic 'Implementation of tagging heat stacks, created by murano' is already
taken,
but we can offer you another one after talking to you about what you are
interesting in.

You can go to #murano channel on IRC node and reach me (katyafervent) or
someone else.
Also, you can contact me directly by mail.


Regards,
Kate.


On Sat, Sep 26, 2015 at 11:20 PM, Amate Yolande 
wrote:

> Hello
>
> My name is Amate Yolande from Buea Cameroon. I am new to open source
> and I am interested in participating in the Outreachy. I would like to
> work on the "Murano - Implementation of tagging heat stacks, created
> by murano" project and would like to get some directives on how to
> familiarize myself with the project. So far I have been able to
> install and test OpenStack from dev-stack on a spare computer using a
> local network at home.
>
> Thanks
> Yolande
>
> __
> 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] -1 due to line length violation in commit messages

[Gorka Eguileor]

On 28/09, Andreas Jaeger wrote:
> On 2015-09-28 11:47, Gorka Eguileor wrote:
> >On 26/09, Morgan Fainberg wrote:
> >>As a core (and former PTL) I just ignored commit message -1s unless there 
> >>is something majorly wrong (no bug id where one is needed, etc).
> >>
> >>I appreciate well formatted commits, but can we let this one go? This 
> >>discussion is so far into the meta-bike-shedding (bike shedding about bike 
> >>shedding commit messages) ... If a commit message is *that* bad a -1 (or 
> >>just fixing it?) Might be worth it. However, if a commit isn't missing key 
> >>info (bug id? Bp? Etc) and isn't one long incredibly unbroken sentence 
> >>moving from topic to topic, there isn't a good reason to block the review.
> >>
> >>It is not worth having a bot -1 bad commits or even having gerrit muck with 
> >>them. Let's do the job of the reviewer and actually review code instead of 
> >>going crazy with commit messages.
> >>
> >>Sent via mobile
> >>
> >
> >I have to disagree, as reviewers we have to make sure that guidelines
> >are followed, if we have an explicit guideline that states that
> >the limit length is 72 chars, I will -1 any patch that doesn't follow
> >the guideline, just as I would do with i18n guideline violations.
> > [...]
> 
> You could also tell the committer about the length so that s/he learns for
> the next time. Giving a -1 just for a few lines that are 80 chars long is
> over the top IMHO,
> 
> Andreas
> -- 

I tell the committer of this guideline, just like it was told to me on
my first commits; and I agree that it sucks to give or receive a -1 for
this, but let me put it this way, how many times will you be
getting/giving a -1 to the same person for this?

If it's a first time committer you'll probably say it once, they'll
learn it, fix it and them we have all our commits conforming to our
guidelines, not such a big deal (although I agree with Miguel Angel that
this should be automated) and if it's not a first time committer he
should have known better and he deserves the -1 for not paying attention
and/or not having his dev env properly setup.


>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
> 
> 
> __
> 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] [ptls] Asserting that your projects follow at least the base deprecation policy

[Thierry Carrez]

Hi everyone,

Last week at the Technical Committee meeting, following the discussion
on this mailing-list a few weeks ago, we finally passed a definition[1]
for a standard base deprecation policy for OpenStack projects.

[1]
http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html

This is expressed as a tag that project teams can choose to add to
specific deliverables that they produce, to assert that they will follow
(at the very least) this base deprecation policy when it comes to
removing features or configuration options in that project. It is meant
to convey that minimal insurance to downstream consumers of that project.

It's worth noting that it's completely fine for a given deliverable to
*not* assert that. Complying with this policy has a cost, as it forces a
time-constrained process and imposes to maintain features in the code
during the deprecation period, distracting useful resources from pure
development. Young or fast-moving projects may not be able or willing to
slow down and to pay that cost at this stage of their development. This
tag requires a certain maturity and stability which some projects have
just not reached yet.

If you want to assert that a service your team delivers will, starting
with their Liberty release, follow that base deprecation policy, you can
propose a change adding that tag to the corresponding deliverable in the
reference/projects.yaml file in the openstack/governance repository.

Thanks in advance!

-- 
Thierry Carrez (ttx)

__
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][nova] how to upgrade from v1 to v2?

[Sean Dague]

On 09/25/2015 08:16 PM, Monty Taylor wrote:
> On 09/25/2015 06:37 PM, Chris Hoge wrote:
>>
>>> On Sep 25, 2015, at 10:12 AM, Andrew Laski >> > wrote:
>>>
>>> I understand that reasoning, but still am unsure on a few things.
>>>
>>> The direction seems to be moving towards having a requirement that the
>>> same functionality is offered in two places, Nova API and Glance V2
>>> API. That seems like it would fragment adoption rather than unify it.
>>
>> My hope would be that proxies would be deprecated as new capabilities
>> moved in. Some of this will be driven by application developers too,
>> though. We’re looking at an interoperability standard, which has a
>> natural tension between backwards compatibility and new features.
> 
> Yeah. The proxies are also less efficient, because they have to bounce
> through two places.

The social theory on the proxies is also that they are fully frozen. So
assuming there would be new good features that people want / need from
projects, they'll naturally migrate to newer direct APIs. More carrot
than stick.

Just pulling APIs that work for people is a good way to make people mad
at you. But giving a gentle nudge because we're never adding new
goodness here is fine.

-Sean

-- 
Sean Dague
http://dague.net

__
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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[masoom alam]

Please help, its not working:

root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
port-show 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
+---+-+
| Field | Value
  |
+---+-+
| admin_state_up| True
   |
| allowed_address_pairs | {"ip_address": "10.0.0.201", "mac_address":
"fa:16:3e:69:e9:ef"}|
| binding:host_id   | openstack-latest-kilo-28-09-2015-masoom
  |
| binding:profile   | {}
   |
| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
   |
| binding:vif_type  | ovs
  |
| binding:vnic_type | normal
   |
| device_id | d44b9025-f12b-4f85-8b7b-57cc1138acdd
   |
| device_owner  | compute:nova
   |
| extra_dhcp_opts   |
  |
| fixed_ips | {"subnet_id":
"bbb6726a-937f-4e0d-8ac2-f82f84272b1f", "ip_address": "10.0.0.3"} |
| id| 2d1bfe12-7db6-4665-9c98-6b9b8a043af9
   |
| mac_address   | fa:16:3e:69:e9:ef
  |
| name  |
  |
| network_id| ae1b7e34-9f6c-4c8f-bf08-99a1e390034c
   |
| security_groups   | 8adda6d7-1b3e-4047-a130-a57609a0bd68
   |
| status| ACTIVE
   |
| tenant_id | 09945e673b7a4ab183afb166735b4fa7
   |
+---+-+

root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9  --allowed-address-pairs
[] action=clear
AllowedAddressPair must contain ip_address


root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9  --allowed-address-pairs
[10.0.0.201] action=clear
The number of allowed address pair exceeds the maximum 10.

root@openstack-latest-kilo-28-09-2015-masoom:/opt/stack/devstack# neutron
port-update 2d1bfe12-7db6-4665-9c98-6b9b8a043af9  --allowed-address-pairs
 action=clear
Request Failed: internal server error while processing your request.




On Mon, Sep 28, 2015 at 1:57 AM, Akihiro Motoki  wrote:

> As already mentioned, we need to pass [] (an empty list) rather than None
> as allowed_address_pairs.
>
> At the moment it is not supported in Neutron CLI.
> This review https://review.openstack.org/#/c/218551/ is trying to fix
> this problem.
>
> Akihiro
>
>
> 2015-09-28 15:51 GMT+09:00 shihanzhang :
>
>> I don't see any exception using bellow command
>>
>> root@szxbz:/opt/stack/neutron# neutron port-update
>> 3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
>> Allowed address pairs must be a list.
>>
>>
>>
>> At 2015-09-28 14:36:44, "masoom alam"  wrote:
>>
>> stable KILO
>>
>> shall I checkout the latest code are you saying this...Also can you
>> please confirm if you have tested this thing at your endand there was
>> no problem...
>>
>>
>> Thanks
>>
>> On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang 
>> wrote:
>>
>>> which branch do you use?  there is not this problem in master branch.
>>>
>>>
>>>
>>>
>>>
>>> At 2015-09-28 13:43:05, "masoom alam"  wrote:
>>>
>>> Can anybody highlight why the following command is throwing an exception:
>>>
>>> *Command#* neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3
>>> --allowed-address-pairs action=clear
>>>
>>> *Error: * 2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource
>>> [req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
>>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most
>>> recent call last):
>>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>>> "/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
>>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result =
>>> method(request=request, **args)
>>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>>> "/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
>>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
>>> allow_bulk=self._allow_bulk)
>>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>>> "/opt/stack/neutron/neutron/api/v2/base.py", line 652, in
>>> prepare_request_body
>>> 2015-09-27 21:44:32.144 TRACE 

[openstack-dev] [nova] Liberty and Nova Specs, Blueprints and Design Summit for Mitaka

[John Garbutt]

Hi,

A quick update on where we are at.

Liberty
-

Its time to give RC1 an good test.

We need to keep our eyes out for release blockers, using this tag:
https://bugs.launchpad.net/nova/+bugs?field.tag=liberty-rc-potential

We will need an new tag on or after 8th October, to include translation updates.

Mitaka
-

If you had something approved in Liberty, it needs to be re-approved for Mitaka.
(We spoke at length about the pros and cons of alternatives at the
midcylce, see etherpad).

Lets try get most specs *merged* before the summit.
And most spec-less blueprints approved too.
Stuff we can't agree on, can then try to get time at the summit.

To help set the priority of spec reviews, we are trying to categories
the specs and blueprints in this etherpad:
https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking

Note: please also put any specless blueprints into the above etherpad,
so they can get reviewed by nova-drivers, so we can vote on them at
the next Nova meeting.

Design Summit
--

For things that can't be agreed in a spec, and/or needs in person
discussion, please do submit a summit session here:
http://goo.gl/forms/D2Qk8XGhZ6

If that does work for you, please see:
https://etherpad.openstack.org/p/mitaka-nova-summit-suggestions

The deadline for proposals will likely be Tuesday 6th October, 23.59
UTC, so we can have a draft ready by Thursday 8th October, and get
everything set in stone before Thursday 16th October.


I suspect I forgot something important... As usual, do catch me via
email or IRC if there are any questions.

Thanks,
johnthetubaguy

__
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] [puppet] weekly meeting #53

[Emilien Macchi]

Hello!

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150929

Feel free to add any additional items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.

Regards,
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
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] Consistent support for SSL termination proxies across all API services

[Sean Dague]

On 09/28/2015 05:01 AM, Julien Danjou wrote:
> On Wed, Sep 23 2015, Julien Danjou wrote:
> 
> 
> […]
> 
>> I'm willing to clear that out and come with specs and patches if that
>> can help. :)
> 
> Following-up on myself, I went ahead and I wrote a more complete version
> of the current proxy middleware we have – which also supports RFC7239:
> 
>   https://review.openstack.org/#/c/227868/
> 
> With that in place, having a proxy (SSL or not) correctly configured in
> front of any WSGI application should be completely transparent for the
> application, with no need of additional configuration.
> 
> If that suits everyone, I'll then propose deprecation of the
> oslo_middleware.ssl middleware in favor of this one.

Great, thanks, Julien, that looks like a good ball to move forward here
in Mitaka. My +1 added to the patch.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
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][nova] how to upgrade from v1 to v2?

[Sean Dague]

On 09/27/2015 08:43 AM, Doug Hellmann wrote:
> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:
>>>
>>> Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:

>>
>> Ah.  Thanks for bringing that up, because I think this may be an area where 
>> there’s some misconception about what DefCore is set up to do today.  In 
>> it’s present form, the Board of Directors has structured DefCore to look 
>> much more at trailing indicators of market acceptance rather than future 
>> technical direction.  More on that over here. [1] 
> 
> And yet future technical direction does factor in, and I'm trying
> to add a new heuristic to that aspect of consideration of tests:
> Do not add tests that use proxy APIs.
> 
> If there is some compelling reason to add a capability for which
> the only tests use a proxy, that's important feedback for the
> contributor community and tells us we need to improve our test
> coverage. If the reason to use the proxy is that no one is deploying
> the proxied API publicly, that is also useful feedback, but I suspect
> we will, in most cases (glance is the exception), say "Yeah, that's
> not how we mean for you to run the services long-term, so don't
> include that capability."

I think we might also just realize that some of the tests are using the
proxy because... that's how they were originally written. And they could
be rewritten to use native APIs. Realistically I think use of the image
proxy in Tempest is mostly because the nova API (with proxy) was easier
to write to... 3 years ago.

Changing these tests is definitely a thing that's on the table when they
do a funny thing.

I do agree that "testing proxies" should not be part of Defcore, and I
like Doug's idea of making that a new heuristic in test selection.

>>> situation for us to be relying on any proxy APIs like this. Yes,
>>> they are widely deployed, but we want to be using glance for image
>>> features, neutron for networking, etc. Having the nova proxy is
>>> fine, but while we have DefCore using tests to enforce the presence
>>> of the proxy we can't deprecate those APIs.
>>
>>
>> Actually that’s not true: DefCore can totally deprecate things too, and can 
>> do so in response to the technical community deprecating things.  See my 
>> comments in this review [2].  Maybe I need to write another post about 
>> that...
> 
> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
> those APIs in DefCore as a reason to avoid deprecating them in the code
> even if they wanted to consider them as legacy features that should be
> removed. Maybe that's not true, and the Nova team would be happy to
> deprecate the APIs, but I did think that part of the feedback cycle we
> were establishing here was to have an indication from the outside of the
> contributor base about what APIs are considered important enough to keep
> alive for a long period of time.

I'd also agree with this. Defcore is a wider contract that we're trying
to get even more people to write to because that cross section should be
widely deployed. So deprecating something in Defcore is something I
think most teams, Nova included, would be very reluctant to do. It's
just asking for breaking your users.

-Sean

-- 
Sean Dague
http://dague.net

__
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] -1 due to line length violation in commit messages

[Andreas Jaeger]

On 2015-09-28 11:47, Gorka Eguileor wrote:

On 26/09, Morgan Fainberg wrote:

As a core (and former PTL) I just ignored commit message -1s unless there is 
something majorly wrong (no bug id where one is needed, etc).

I appreciate well formatted commits, but can we let this one go? This 
discussion is so far into the meta-bike-shedding (bike shedding about bike 
shedding commit messages) ... If a commit message is *that* bad a -1 (or just 
fixing it?) Might be worth it. However, if a commit isn't missing key info (bug 
id? Bp? Etc) and isn't one long incredibly unbroken sentence moving from topic 
to topic, there isn't a good reason to block the review.

It is not worth having a bot -1 bad commits or even having gerrit muck with 
them. Let's do the job of the reviewer and actually review code instead of 
going crazy with commit messages.

Sent via mobile



I have to disagree, as reviewers we have to make sure that guidelines
are followed, if we have an explicit guideline that states that
the limit length is 72 chars, I will -1 any patch that doesn't follow
the guideline, just as I would do with i18n guideline violations.

> [...]

You could also tell the committer about the length so that s/he learns 
for the next time. Giving a -1 just for a few lines that are 80 chars 
long is over the top IMHO,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
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][nova] how to upgrade from v1 to v2?

[John Garbutt]

On 28 September 2015 at 12:10, Sean Dague  wrote:
> On 09/27/2015 08:43 AM, Doug Hellmann wrote:
>> Excerpts from Mark Voelker's message of 2015-09-25 20:43:23 +:
>>> On Sep 25, 2015, at 1:56 PM, Doug Hellmann  wrote:

 Excerpts from Mark Voelker's message of 2015-09-25 17:42:24 +:
> 
>>>
>>> Ah.  Thanks for bringing that up, because I think this may be an area where 
>>> there’s some misconception about what DefCore is set up to do today.  In 
>>> it’s present form, the Board of Directors has structured DefCore to look 
>>> much more at trailing indicators of market acceptance rather than future 
>>> technical direction.  More on that over here. [1]
>>
>> And yet future technical direction does factor in, and I'm trying
>> to add a new heuristic to that aspect of consideration of tests:
>> Do not add tests that use proxy APIs.
>>
>> If there is some compelling reason to add a capability for which
>> the only tests use a proxy, that's important feedback for the
>> contributor community and tells us we need to improve our test
>> coverage. If the reason to use the proxy is that no one is deploying
>> the proxied API publicly, that is also useful feedback, but I suspect
>> we will, in most cases (glance is the exception), say "Yeah, that's
>> not how we mean for you to run the services long-term, so don't
>> include that capability."
>
> I think we might also just realize that some of the tests are using the
> proxy because... that's how they were originally written.

From my memory, thats how we got here.

The Nova tests needed to use an image API. (i.e. list images used to
check the snapshot Nova, or similar)

The Nova proxy was chosen over Glance v1 and Glance v2, mostly due to
it being the only widely deployed option.

> And they could be rewritten to use native APIs.

+1
Once Glance v2 is available.

Adding Glance v2 as advisory seems a good step to help drive more adoption.

> I do agree that "testing proxies" should not be part of Defcore, and I
> like Doug's idea of making that a new heuristic in test selection.

+1
Thats a good thing to add.
But I don't think we had another option in this case.

>> Sorry, I wasn't clear. The Nova team would, I expect, view the use of
>> those APIs in DefCore as a reason to avoid deprecating them in the code
>> even if they wanted to consider them as legacy features that should be
>> removed. Maybe that's not true, and the Nova team would be happy to
>> deprecate the APIs, but I did think that part of the feedback cycle we
>> were establishing here was to have an indication from the outside of the
>> contributor base about what APIs are considered important enough to keep
>> alive for a long period of time.
> I'd also agree with this. Defcore is a wider contract that we're trying
> to get even more people to write to because that cross section should be
> widely deployed. So deprecating something in Defcore is something I
> think most teams, Nova included, would be very reluctant to do. It's
> just asking for breaking your users.

I can't see us removing the proxy APIs in Nova any time soon,
regardless of DefCore, as it would break too many people.

But personally, I like dropping them from Defcore, to signal that the
best practice is to use the Glance v2 API directly, rather than the
Nova proxy.

Maybe the are just marked deprecated, but still required, although
that sounds a bit crazy.

Thanks,
johnthetubaguy

 situation for us to be relying on any proxy APIs like this. Yes,
 they are widely deployed, but we want to be using glance for image
 features, neutron for networking, etc. Having the nova proxy is
 fine, but while we have DefCore using tests to enforce the presence
 of the proxy we can't deprecate those APIs.
>>>
>>>
>>> Actually that’s not true: DefCore can totally deprecate things too, and can 
>>> do so in response to the technical community deprecating things.  See my 
>>> comments in this review [2].  Maybe I need to write another post about 
>>> that...
>>
>
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Sylvain Bauza]

Le 28/09/2015 11:23, Duncan Thomas a écrit :


The trouble with putting more intelligence in the clients is that 
there are more clients than just the one we provide, and the more 
smarts we require in the clients, the more divergence of functionality 
we're likely to see. Also, bugs and slowly percolating bug fixes.




That's why I consider the layer of orchestration in the client just 
being as identical as what we have in Nova, not more than that. If we 
require more than just a volume creation when asking to boot from a 
volume with source=image, then I agree with you, it has nothing to do in 
the client, but rather in Heat.


The same goes with networks. What is done with Nova for managing CRUD 
operations can be done in python clients, but that's the limit.


About the maintenance burden, I also consider that patching clients is 
far more easier than patching an API unless I missed something.


-Sylvain


On 28 Sep 2015 11:27, "Sylvain Bauza" > wrote:




Le 25/09/2015 16:12, Andrew Laski a écrit :

On 09/24/15 at 03:13pm, James Penick wrote:



At risk of getting too offtopic I think there's an
alternate solution to
doing this in Nova or on the client side.  I think
we're missing some sort
of OpenStack API and service that can handle this. 
Nova is a low level

infrastructure API and service, it is not designed to
handle these
orchestrations.  I haven't checked in on Heat in a
while but perhaps this
is a role that it could fill.

I think that too many people consider Nova to be *the*
OpenStack API when
considering instances/volumes/networking/images and
that's not something I
would like to see continue.  Or at the very least I
would like to see a
split between the orchestration/proxy pieces and the
"manage my
VM/container/baremetal" bits



(new thread)
You've hit on one of my biggest issues right now: As far
as many deployers
and consumers are concerned (and definitely what I tell my
users within
Yahoo): The value of an OpenStack value-stream (compute,
network, storage)
is to provide a single consistent API for abstracting and
managing those
infrastructure resources.

Take networking: I can manage Firewalls, switches, IP
selection, SDN, etc
through Neutron. But for compute, If I want VM I go
through Nova, for
Baremetal I can -mostly- go through Nova, and for
containers I would talk
to Magnum or use something like the nova docker driver.

This means that, by default, Nova -is- the closest thing
to a top level
abstraction layer for compute. But if that is explicitly
against Nova's
charter, and Nova isn't going to be the top level
abstraction for all
things Compute, then something else needs to fill that
space. When that
happens, all things common to compute provisioning should
come out of Nova
and move into that new API. Availability zones, Quota, etc.


I do think Nova is the top level abstraction layer for
compute. My issue is when Nova is asked to manage other
resources.  There's no API call to tell Cinder "create a
volume and attach it to this instance, and create that
instance if it doesn't exist."  And I'm not sure why the
reverse isn't true.

I want Nova to be the absolute best API for managing compute
resources.  It's when someone is managing compute and volumes
and networks together that I don't feel that Nova is the best
place for that.  Most importantly right now it seems that not
everyone is on the same page on this and I think it would be
beneficial to come together and figure out what sort of
workloads the Nova API is intending to provide.


I totally agree with you on those points :
 - nova API should be only supporting CRUD operations for compute
VMs and should no longer manage neither volumes nor networks IMHO,
because it creates more problems than it resolves
 - given the above, nova API could possibly accept resources from
networks or volumes but only for placement decisions related to
instances.

Tho, I can also understand that operators sometimes just want a
single tool for creating this kind of relationship between a
volume and an instance (and not provide a YAML file), but IMHO, it
doesn't perhaps need a top-level API, just a 

Re: [openstack-dev] Murano code flow for custom development and combining murano with horizon in devstack

[Kirill Zaitsev]

Hi, murano-dashboard works the same way any other horizon dashboard does.

I’m not quite sure, what you meant by «combined and showed under one tab», 
could you please elaborate?
If you’re asking about debugging — you can install murano-dashboard locally and 
configure it to use remote cloud (i.e. devstack) as descried here 
http://murano.readthedocs.org/en/latest/install/manual.html#install-murano-dashboard
 . If not — then I did’t quite understood what you asked in the first place =)

Feel free to come and ask around in #murano — you might get help there faster 
then on ML =)  

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 26 Sep 2015 at 02:24:10, Sumanth Sathyanarayana 
(sumanth.sathyanaray...@gmail.com) wrote:

Hello,

Could anyone let me know if the changes in murano dashboard and horizon's 
openstackdashboard, both be combined and showed under one tab.
i.e. say under Murano tab on the side left panel all the changes done in 
horizon and murano both appear.

If anyone could point me to a link explaining custom development of murano and 
the code flow would be very helpful...

Thanks & Best Regards
Sumanth

__  
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] KILO: neutron port-update --allowed-address-pairs action=clear throws an exception

[Akihiro Motoki]

As already mentioned, we need to pass [] (an empty list) rather than None
as allowed_address_pairs.

At the moment it is not supported in Neutron CLI.
This review https://review.openstack.org/#/c/218551/ is trying to fix this
problem.

Akihiro


2015-09-28 15:51 GMT+09:00 shihanzhang :

> I don't see any exception using bellow command
>
> root@szxbz:/opt/stack/neutron# neutron port-update
> 3748649e-243d-4408-a5f1-8122f1fbf501 --allowed-address-pairs action=clear
> Allowed address pairs must be a list.
>
>
>
> At 2015-09-28 14:36:44, "masoom alam"  wrote:
>
> stable KILO
>
> shall I checkout the latest code are you saying this...Also can you please
> confirm if you have tested this thing at your endand there was no
> problem...
>
>
> Thanks
>
> On Sun, Sep 27, 2015 at 11:29 PM, shihanzhang 
> wrote:
>
>> which branch do you use?  there is not this problem in master branch.
>>
>>
>>
>>
>>
>> At 2015-09-28 13:43:05, "masoom alam"  wrote:
>>
>> Can anybody highlight why the following command is throwing an exception:
>>
>> *Command#* neutron port-update db3113df-14a3-4d6d-a3c5-d0517a134fc3
>> --allowed-address-pairs action=clear
>>
>> *Error: * 2015-09-27 21:44:32.144 ERROR neutron.api.v2.resource
>> [req-b1cbe1f2-ba21-4337-a714-f337c54ee9fc admin None] update failed
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource Traceback (most
>> recent call last):
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>> "/opt/stack/neutron/neutron/api/v2/resource.py", line 83, in resource
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource result =
>> method(request=request, **args)
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>> "/opt/stack/neutron/neutron/api/v2/base.py", line 515, in update
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
>> allow_bulk=self._allow_bulk)
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>> "/opt/stack/neutron/neutron/api/v2/base.py", line 652, in
>> prepare_request_body
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
>> attr_vals['validate'][rule])
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource   File
>> "/opt/stack/neutron/neutron/extensions/allowedaddresspairs.py", line 51, in
>> _validate_allowed_address_pairs
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource if
>> len(address_pairs) > cfg.CONF.max_allowed_address_pair:
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource TypeError: object
>> of type 'NoneType' has no len()
>> 2015-09-27 21:44:32.144 TRACE neutron.api.v2.resource
>>
>>
>>
>> There is a similar bug filed at Lauchpad for Havana
>> https://bugs.launchpad.net/juniperopenstack/+bug/1351979 .However there
>> is no fix and the work around  - using curl, mentioned on the bug is also
>> not working for KILO...it was working for havana and Icehouseany
>> pointers...?
>>
>> Thanks
>>
>>
>>
>>
>> 网易考拉iPhone6s玫瑰金5288元，现货不加价
>> 
>>
>> __
>> 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
>>
>>
>
>
> 网易考拉iPhone6s玫瑰金5288元，现货不加价
> 
>
> __
> 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] -1 due to line length violation in commit messages

[Miguel Angel Ajo]

IMO those checks should be automated, as we automate pep8 checks on our
python code.

I agree, that if we have a rule for this, we should follow it, but it's 
a waste

of time reviewing and enforcing this manually.

Best regards.
Miguel Ángel.

Gorka Eguileor wrote:

On 26/09, Morgan Fainberg wrote:

As a core (and former PTL) I just ignored commit message -1s unless there is 
something majorly wrong (no bug id where one is needed, etc).

I appreciate well formatted commits, but can we let this one go? This 
discussion is so far into the meta-bike-shedding (bike shedding about bike 
shedding commit messages) ... If a commit message is *that* bad a -1 (or just 
fixing it?) Might be worth it. However, if a commit isn't missing key info (bug 
id? Bp? Etc) and isn't one long incredibly unbroken sentence moving from topic 
to topic, there isn't a good reason to block the review.

It is not worth having a bot -1 bad commits or even having gerrit muck with 
them. Let's do the job of the reviewer and actually review code instead of 
going crazy with commit messages.

Sent via mobile



I have to disagree, as reviewers we have to make sure that guidelines
are followed, if we have an explicit guideline that states that
the limit length is 72 chars, I will -1 any patch that doesn't follow
the guideline, just as I would do with i18n guideline violations.

Typos are a completely different matter and they should not be grouped
together with guideline infringements.

I agree that it is a waste of time and resources when you have to -1 a
patch for this, but there multiple solutions, you can make sure your
editor does auto wrapping at the right length (I have mine configured
this way), or create a git-enforce policy with a client-side hook, or do
like Ihar is trying to do and push for a guideline change.

I don't mind changing the guideline to any other length, but as long as
it is 72 chars I will keep enforcing it, as it is not the place of
reviewers to decide which guidelines are worthy of being enforced and
which ones are not.

Cheers,
Gorka.




On Sep 26, 2015, at 21:19, Ian Wells  wrote:

Can I ask a different question - could we reject a few simple-to-check things 
on the push, like bad commit messages?  For things that take 2 seconds to fix 
and do make people's lives better, it's not that they're rejected, it's that 
the whole rejection cycle via gerrit review (push/wait for tests to run/check 
website/swear/find change/fix/push again) is out of proportion to the effort 
taken to fix it.

It seems here that there's benefit to 72 line messages - not that everyone sees 
that benefit, but it is present - but it doesn't outweigh the current cost.
--
Ian.



On 25 September 2015 at 12:02, Jeremy Stanley  wrote:
On 2015-09-25 16:15:15 + (+), Fox, Kevin M wrote:

Another option... why are we wasting time on something that a
computer can handle? Why not just let the line length be infinite
in the commit message and have gerrit wrap it to  length lines on merge?

The commit message content (including whitespace/formatting) is part
of the data fed into the hash algorithm to generate the commit
identifier. If Gerrit changed the commit message at upload, that
would alter the Git SHA compared to your local copy of the same
commit. This quickly goes down a Git madness rabbit hole (not the
least of which is that it would completely break signed commits).
--
Jeremy Stanley

__
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



__
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][stable][release][horizon] 2015.1.2

[Matthias Runge]

On 25/09/15 15:39, Ihar Hrachyshka wrote:

> I see you have three people in the horizon-stable-maint team only. 
> Have you considered expanding the team with more folks? In
> neutron, we have five people in the stable-maint group.

Good suggestion!

In horizon, we just have a very few cores being in charge to support a
installation or a distribution.

So: if any of you considering themself to be a good candidate for
being a stable reviewer, please speak up!

For Horizon, I will ping Horizon cores asking them to join
horizon-stable-maint team.

Matthias


__
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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Duncan Thomas]

On 28 September 2015 at 12:35, Sylvain Bauza  wrote:

> About the maintenance burden, I also consider that patching clients is far
> more easier than patching an API unless I missed something.
>
>
I think I very much disagree there - patching a central installation is
much, much easier than getting N customers to patch M different libraries,
even assuming the fix is available for any significant subset of the M
libraries, plus making sure that new customers use the correct libraries,
plus helping any customers who have some sort of roll-your-own library do
the new right thing...

I think there's a definite place for a simple API to do infrastructure
level orchestration without needing the complexities of heat - these APIs
are in nova because they're useful - there's clear operator desire for them
and a couple of operators have been quite vocal about their desire for them
not to be removed. Great, let's keep them, but form a team of people
interested in getting them right (get rid of fixed timeouts, etc), add any
missing pieces (like floating IPs for new VMs) and generally focus on
getting this piece of the puzzle right. Breaking another small piece off
nova and polishing it has been a generally successful pattern.

I remember Monty Taylor (copied) having a rant about the lack of the
perfect 'give me a VM with all its stuff sorted' API. Care to comment,
Monty?
__
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] [mistral] Cancelling team meeting today (09/28/2015)

[Nikolay Makhotkin]

Mistral Team,

We’re cancelling today’s team meeting because a number of key members won’t
be able to attend.

The next one is scheduled for 5 Oct.


Best Regards,
Nikolay Makhotkin
@Mirantis Inc.
__
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