Re: [openstack-dev] [CI]How to set proxy for nodepool

[Xie, Xianshan]

Hi Ramy,
Thanks for your help.

I have already confirmed proxy setting again, and it works fine(no matter 
whether the NODEPOOL_ variables are declared or not):

1)   not only in the host machine on which DIB run,

2)   but also in the first half part of DIB(before the DIB running chroot).

3)   furthmore, I ran the commands manually in the host env, they also 
works fine.

$ sudo -H virtualenv /usr/zuul-swift-logs-env

$ sudo -H /usr/zuul-swift-logs-env/bin/pip install python-magic argparse 
requests glob2

So, if I understood correctly, it seems obvious, that the proxy setting is 
missed when DIB goes into chroot env.
Thus, when DIB attempts to connect internet to download/install/update some 
materials to prepare the image within the chroot env, the error will be 
encountered.
In this case, DIB will run “pip install” in the chroot env zuul-swift-logs-env 
to install python-magic, argparse and so forth.

Actually, all NODEPOOL_ variables were already declared by the 
install_master.sh previously, and the proxy setting also derived from the host 
machine`s proxy setting.

Xiexs
From: Asselin, Ramy [mailto:ramy.asse...@hp.com]
Sent: Tuesday, August 04, 2015 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [CI]How to set proxy for nodepool

Hi Xiexs,

You are using disk image builder (DIB), so make sure your proxy is set 
correctly also without the NODEPOOL_ prefix.
Those NODEPOOL_ prefixed variables are what would be used when DIB is not used 
/ when the script approach is used with nova/glance (nodepool image-update). I 
don’t recommend using that if you can use DIB.

Also, I’ve found some of the infra project-config elements don’t work in my 
environment and aren’t needed as they’re specific to infra. For those, simply 
comment out the portions that don’t work. I didn’t notice any negative 
side-effects.

Ramy

From: Xie, Xianshan [mailto:xi...@cn.fujitsu.com]
Sent: Monday, August 03, 2015 9:37 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [CI]How to set proxy for nodepool

Hi All,
When I ran “nodepool image-build ” to create a new image, I got 
this error message:
…
INFO nodepool.image.build.dpc: + sudo -H virtualenv /usr/zuul-swift-logs-env
INFO nodepool.image.build.dpc: sudo: unable to resolve host fnst01
INFO nodepool.image.build.dpc: + sudo -H /usr/zuul-swift-logs-env/bin/pip 
install python-magic argparse requests glob2
INFO nodepool.image.build.dpc: sudo: unable to resolve host fnst01
INFO nodepool.image.build.dpc: Collecting python-magic
INFO nodepool.image.build.dpc: Retrying (Retry(total=4, connect=None, 
read=None, redirect=None)) after connection broken by 
'ProtocolError('Connection aborted.', gaierror(-5, 'No address associated with 
hostname'))': /simple/python-magic/
INFO nodepool.image.build.dpc: Retrying (Retry(total=3, connect=None, 
read=None, redirect=None)) after connection broken by 
'ProtocolError('Connection aborted.', gaierror(-5, 'No address associated with 
hostname'))': /simple/python-magic/
…

And I exported the bash env when the script 
elements/nodepool-base/install.d/90-venv-swift-logs ran,
it seems that the nodepool proxy and dns has already been set:

declare -x NODEPOOL_HTTPS_PROXY=http://xx.xx.xx.xx:8080/  <--valid proxy
declare -x NODEPOOL_HTTP_PROXY="http://xx.xx.xx.xx:8080/";
declare -x NODEPOOL_NO_PROXY="localhost,127.0.0.1"
declare -x NODEPOOL_SCRIPTDIR="/etc/nodepool/scripts"
declare -x NODEPOOL_STATIC_NAMESERVER="xx.xx.xx.xx"
declare -x PS1="(zuul-swift-logs-env)"
INFO nodepool.image.build.dpc: + cat /etc/resolv.conf
INFO nodepool.image.build.dpc: nameserver xx.xx.xx.xx   <--valid dns

And I have tried to add element “local-config” into nodepool.yaml, but it does 
not work.

So, my questions are:

1)  These bash env will be passed into the virtualenv zuul-swift-logs-env 
after chroot, is it right?

2)  If not, how to configure the proxy for nodepool?

Many thanks to any suggestion.

Xiexs
__
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] A possible solution for HA Active-Active

[Duncan Thomas]

On 3 August 2015 at 20:53, Clint Byrum  wrote:

> Excerpts from Devananda van der Veen's message of 2015-08-03 08:53:21
> -0700:
> Also on a side note, I think Cinder's need for this is really subtle,
> and one could just accept that sometimes it's going to break when it does
> two things to one resource from two hosts. The error rate there might
> even be lower than the false-error rate that would be caused by a twitchy
> DLM with timeouts a little low. So there's a core cinder discussion that
> keeps losing to the shiny DLM discussion, and I'd like to see it played
> out fully: Could Cinder just not do anything, and let the few drivers
> that react _really_ badly, implement their own concurrency controls?
>


So the problem here is data corruption. Lots of our races can cause data
corruption. Not 'my instance didn't come up', not 'my network is screwed
and I need to tear everything down and do it again', but 'My 1tb of
customer database is now missing the second half'. This means that we
*really* need some confidence and understanding in whatever we do. The idea
of locks timing out and being stolen without fencing is frankly scary and
begging for data corruption unless we're very careful. I'd rather use a
persistent lock (e.g. a db record change) and manual recovery than a lock
timeout that might cause corruption.


-- 
Duncan Thomas
__
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][neutron] How to give nested VM access to outside network?

[Andreas Scheuring]

Can you try answer 1 of [1]?

I've never tried it, but I heard from folks who configured it like that.
With this masquerading, your vm should be able to reach your 192.x
network. But as it's NAT it won't work the other way round (e.g.
establish a connection from outside into your vm)

The proper way would be to configure your provider network to match the
192.x subnet. In addition you would need to plug your 192.x interface
(eth0)? into the ovs br-ex. But be careful! This steps breaks
connectivity via this interface. So be sure that you're logged in via
another interface or via some vnc session. 

If you have further questions regarding provider networks, feel free to
ask again!



[1]
https://ask.openstack.org/en/question/44266/connect-vm-in-devstack-to-external-network/


On Mo, 2015-08-03 at 22:07 -0600, Rich Megginson wrote:
> I'm running devstack in a VM (Fedora 21 host, EL 7.1.x VM) with a static 
> IP address (because dhcp was not working):
> 
>  cat > /etc/sysconfig/network-scripts/ifcfg-eth0 < DEVICE="eth0"
> BOOTPROTO="static"
> DHCPCLASS=
> HWADDR=$VM_MAC
> IPADDR=192.168.122.5
> NETMASK=255.255.255.0
> GATEWAY=192.168.122.1
> ONBOOT=yes
> NM_CONTROLLED=no
> TYPE="Ethernet"
> USERCTL="yes"
> PEERDNS="yes"
> DNS1="192.168.122.1"
> IPV6INIT="no"
> EOF
> 
> with Neutron networking enabled and Nova networking disabled:
> 
> [[local|localrc]]
> IP_VERSION=4
> ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-sch,n-cond,n-crt,n-novnc,mysql,rabbit,dstat,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta
> SERVICE_HOST=127.0.0.1
> NETWORK_GATEWAY=10.0.0.1
> PUBLIC_NETWORK_GATEWAY=172.24.4.1
> ...
> 
> I've followed this some, but I don't want to use the provider network: 
> http://docs.openstack.org/developer/devstack/guides/neutron.html
> 
> I've hacked the floating_ips exercise to use neutron networking commands:
> 
> http://ur1.ca/ncjm6
> 
> I can ssh into the nested VM, I can assign it a floating IP.
> 
> However, it cannot see the outside world.  From it, I can ping the 
> 10.0.0.1 network and the 172.24.4.1 network, and even 192.168.122.5, but 
> not 192.168.122.1 or anything outside of the VM.
> 
> route looks like this: http://ur1.ca/ncjog
> 
> ip addr looks like this: http://ur1.ca/ncjop
> 
> Here is the entire output of stack.sh: 
> https://rmeggins.fedorapeople.org/stack.out
> 
> Here is the entire output of the exercise: 
> https://rmeggins.fedorapeople.org/exercise.out
> 
> 
> __
> 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
> 

-- 
Andreas
(IRC: scheuran)



__
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] A possible solution for HA Active-Active

[Gorka Eguileor]

On Tue, Aug 04, 2015 at 10:32:40AM +0300, Duncan Thomas wrote:
> On 3 August 2015 at 20:53, Clint Byrum  wrote:
> 
> > Excerpts from Devananda van der Veen's message of 2015-08-03 08:53:21
> > -0700:
> > Also on a side note, I think Cinder's need for this is really subtle,
> > and one could just accept that sometimes it's going to break when it does
> > two things to one resource from two hosts. The error rate there might
> > even be lower than the false-error rate that would be caused by a twitchy
> > DLM with timeouts a little low. So there's a core cinder discussion that
> > keeps losing to the shiny DLM discussion, and I'd like to see it played
> > out fully: Could Cinder just not do anything, and let the few drivers
> > that react _really_ badly, implement their own concurrency controls?
> >
> 
> 
> So the problem here is data corruption. Lots of our races can cause data
> corruption. Not 'my instance didn't come up', not 'my network is screwed
> and I need to tear everything down and do it again', but 'My 1tb of
> customer database is now missing the second half'. This means that we
> *really* need some confidence and understanding in whatever we do. The idea
> of locks timing out and being stolen without fencing is frankly scary and
> begging for data corruption unless we're very careful. I'd rather use a
> persistent lock (e.g. a db record change) and manual recovery than a lock
> timeout that might cause corruption.
> 
> 
> -- 
> Duncan Thomas


If we end up using a DLM then we have to detect when the connection to
the DLM is lost on a node and stop all ongoing operations to prevent
data corruption.

It may not be trivial to do, but we will have to do it in any solution
we use, even on my last proposal that only uses the DB in Volume Manager
we would still need to stop all operations if we lose connection to the
DB.

Cheers,
Gorka.

__
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] A possible solution for HA Active-Active

[Gorka Eguileor]

On Mon, Aug 03, 2015 at 06:12:23PM +, Fox, Kevin M wrote:
> For example, to parallel the conversation with databases:
> 
> "We want a database". Well, that means mongodb, postgres, mysql, berkeleydb, 
> etc
> 
> "Oh, well, I need it to be a relational db", Well, that means postgresq, 
> mysql, etc
> 
> "Oh, and I need recursive queries"... that excludes even more.
> 
> We are pretty sure "We want a distributed lock manager". What problems are we 
> trying to solve using it, and what features do they require in the DLM/DLM 
> Abstraction of choice? That will exclude some of them. It also may exclude 
> abstraction layers that don't expose the features needed. (Recursive queries 
> for example)
> 
> Thanks,
> Kevin
> 

Kevin all that has already been explained:

http://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/
http://gorka.eguileor.com/simpler-road-to-cinder-active-active/

As well as on IRC and this thread, I don't see the point of repeating it
over and over again, at some point people need to start doing their
homework and read what's already been said to get up to speed on the
topic so we can move on.

Gorka.

> From: Gorka Eguileor [gegui...@redhat.com]
> Sent: Monday, August 03, 2015 10:48 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] A possible solution for   HA  
> Active-Active
> 
> On Mon, Aug 03, 2015 at 03:42:48PM +, Fox, Kevin M wrote:
> > I'm usually for abstraction layers, but they don't always pay off very well 
> > due to catering to the lowest common denominator.
> >
> > Lets clearly define the problem space first. IFF the problem space can be 
> > fully implemented using Tooz, then lets do that. Then the operator can 
> > choose. If Tooz cant and wont handle the problem space, then we're trying 
> > to fit a square peg in a round hole.
> 
> What do you mean with clearly define the problem space?  We know what we
> want, we just need to agree on the compromises we are willing to make,
> use a DLM and make admins' life a little harder (only for those that
> deploy A-A) but have an A-A solution earlier, or postpone A-A
> functionality but make their life easier.
> 
> And we already know that Tooz is not the Holy Grail and will not perform
> the miracle of giving Cinder HA A-A.  It is only a piece of the problem,
> so there's nothing to discuss there, and it's not a square peg on a
> round hole, because it fits perfectly for what it is intended. But once
> you have filled that square hole you need another peg, the round one for
> the round hole.
> 
> If people are expecting to find one thing that fixes everything and
> gives us HA A-A on its own, then I believe they are a little bit lost.
> 
> Gorka.
> 
> >
> > Thanks,
> > Kevin
> > 
> > From: Gorka Eguileor [gegui...@redhat.com]
> > Sent: Monday, August 03, 2015 1:43 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
> > Active-Active
> >
> > On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> > > Flavio Percoco wrote:
> > > > [...]
> > > > So, to summarize, I love the effort behind this. But, as others have
> > > > mentioned, I'd like us to take a step back, run this accross teams and
> > > > come up with an opinonated solution that would work for everyone.
> > > >
> > > > Starting this discussion now would allow us to prepare enough material
> > > > to reach an agreement in Tokyo and work on a single solution for
> > > > Mikata. This sounds like a good topic for a cross-project session.
> > >
> > > +1
> > >
> > > The last thing we want is to rush a solution that would only solve a
> > > particular project use case. Personally I'd like us to pick the simplest
> > > solution that can solve most of the use cases. Each of the solutions
> > > bring something to the table -- Zookeeper is mature, Consul is
> > > featureful, etcd is lean and simple... Let's not dive into the best
> > > solution but clearly define the problem space first.
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> >
> > I don't see those as different solutions from the point of view of
> > Cinder, they are different implementations to the same solution case,
> > using a DLM to lock resources.
> >
> > We keep circling back to the fancy names like moths to a flame, when we
> > are still discussing whether we need or want a DLM for the solution.  I
> > think we should stop doing that, we need to decide on the solution from
> > an abstract point of view (like you say, define the problem space) and
> > not get caught up on discussions of which one of those is best.  If we
> > end up deciding to use a DLM, which is unlikely, then we can look into
> > available drivers in Tooz and if we are not convinced with the ones we
> > have (Redis, ZooKeeper, etc.) then we discuss which one we should be
> > using

Re: [openstack-dev] [Cinder] A possible solution for HA Active-Active

[Gorka Eguileor]

On Tue, Aug 04, 2015 at 05:47:44AM +1000, Morgan Fainberg wrote:
> 
> 
> > On Aug 4, 2015, at 01:42, Fox, Kevin M  wrote:
> > 
> > I'm usually for abstraction layers, but they don't always pay off very well 
> > due to catering to the lowest common denominator.
> > 
> > Lets clearly define the problem space first. IFF the problem space can be 
> > fully implemented using Tooz, then lets do that. Then the operator can 
> > choose. If Tooz cant and wont handle the problem space, then we're trying 
> > to fit a square peg in a round hole.
> > 
> 
> +1 and specifically around tooz, it is narrow in comparison to the feature 
> sets of some the DLMs (since it has to mostly-implement to the lowest common 
> denominator, as abstraction layers do). Defining the space we are trying to 
> target will let us make the informed decision on what we use. 

Again with this?

We already what we want to get out of Tooz, where we want it and for how
long we'll be using it in each of those places.

To answer those questions all that's needed is to read this thread and
the links referred on some conversations.

Gorka.

> 
> > Thanks,
> > Kevin
> > 
> > From: Gorka Eguileor [gegui...@redhat.com]
> > Sent: Monday, August 03, 2015 1:43 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
> > Active-Active
> > 
> >> On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> >> Flavio Percoco wrote:
> >>> [...]
> >>> So, to summarize, I love the effort behind this. But, as others have
> >>> mentioned, I'd like us to take a step back, run this accross teams and
> >>> come up with an opinonated solution that would work for everyone.
> >>> 
> >>> Starting this discussion now would allow us to prepare enough material
> >>> to reach an agreement in Tokyo and work on a single solution for
> >>> Mikata. This sounds like a good topic for a cross-project session.
> >> 
> >> +1
> >> 
> >> The last thing we want is to rush a solution that would only solve a
> >> particular project use case. Personally I'd like us to pick the simplest
> >> solution that can solve most of the use cases. Each of the solutions
> >> bring something to the table -- Zookeeper is mature, Consul is
> >> featureful, etcd is lean and simple... Let's not dive into the best
> >> solution but clearly define the problem space first.
> >> 
> >> --
> >> Thierry Carrez (ttx)
> > 
> > I don't see those as different solutions from the point of view of
> > Cinder, they are different implementations to the same solution case,
> > using a DLM to lock resources.
> > 
> > We keep circling back to the fancy names like moths to a flame, when we
> > are still discussing whether we need or want a DLM for the solution.  I
> > think we should stop doing that, we need to decide on the solution from
> > an abstract point of view (like you say, define the problem space) and
> > not get caught up on discussions of which one of those is best.  If we
> > end up deciding to use a DLM, which is unlikely, then we can look into
> > available drivers in Tooz and if we are not convinced with the ones we
> > have (Redis, ZooKeeper, etc.) then we discuss which one we should be
> > using instead and just add it to Tooz.
> > 
> > Cheers,
> > Gorka.
> > 
> > __
> > 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] [Cinder] A possible solution for HA Active-Active

[Philipp Marek]

> If we end up using a DLM then we have to detect when the connection to
> the DLM is lost on a node and stop all ongoing operations to prevent
> data corruption.
> 
> It may not be trivial to do, but we will have to do it in any solution
> we use, even on my last proposal that only uses the DB in Volume Manager
> we would still need to stop all operations if we lose connection to the
> DB.

Well, is it already decided that Pacemaker would be chosen to provide HA in 
Openstack? There's been a talk "Pacemaker: the PID 1 of Openstack" IIRC.

I know that Pacemaker's been pushed aside in an earlier ML post, but IMO 
there's already *so much* been done for HA in Pacemaker that Openstack 
should just use it.

All HA nodes needs to participate in a Pacemaker cluster - and if one node 
looses connection, all services will get stopped automatically (by 
Pacemaker) - or the node gets fenced.


No need to invent some sloppy scripts to do exactly the tasks (badly!) that 
the Linux HA Stack has been providing for quite a few years.


Yes, Pacemaker needs learning - but not more than any other involved 
project, and there are already quite a few here, which have to be known to 
any operator or developer already.


(BTW, LINBIT sells training for the Linux HA Cluster Stack - and yes,
 I work for them ;)

__
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] [nova][ironic] Scheduler filtering based on instances

[Lucas Alvares Gomes]

Hi,

> Our initial solution [1] was to simply disable instance queries in the
> IronicHostManager, as they were never needed, and were painful to
> execute. But subsequent discussion on IRC brought up some potential
> (although not very likely) use cases where this might not be true. One
> example was if there were two computes each talking to one of two
> ironic installations, one might use the SameHostFilter to ensure that
> a new ironic instance was placed in the same ironic environment as
> another instance. While this seemed possible, the idea of querying
> hundreds or thousands of instances to see if the target was in that
> group seemed like overkill. I suggested that if this were ever
> something that someone needed, creating a new filter would be a better
> way forward than trying to retrofit the virt design onto ironic.
>

Right, so my first suggestion would be to add a configuration option
where one could toggle to enable or disable the new scheduler filters
(defaulting to disabled). But if Nova doesn't want to add a new
configuration option unless it's absolutely necessary I think we could
just disable it for now (just like the patch is proposing right now)
and open a bug about it so we can keep track of the problem. And if we
figure out that this problem is affecting someone out there we can
then fix it by whether adding the configuration option or creating a
new filter or ... We can talk about the proper fix as part of that
bug.

Cheers,
Lucas

__
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] A possible solution for HA Active-Active

[Flavio Percoco]

On 04/08/15 10:50 +0200, Philipp Marek wrote:

If we end up using a DLM then we have to detect when the connection to
the DLM is lost on a node and stop all ongoing operations to prevent
data corruption.

It may not be trivial to do, but we will have to do it in any solution
we use, even on my last proposal that only uses the DB in Volume Manager
we would still need to stop all operations if we lose connection to the
DB.


Well, is it already decided that Pacemaker would be chosen to provide HA in
Openstack? There's been a talk "Pacemaker: the PID 1 of Openstack" IIRC.

I know that Pacemaker's been pushed aside in an earlier ML post, but IMO
there's already *so much* been done for HA in Pacemaker that Openstack
should just use it.

All HA nodes needs to participate in a Pacemaker cluster - and if one node
looses connection, all services will get stopped automatically (by
Pacemaker) - or the node gets fenced.


No need to invent some sloppy scripts to do exactly the tasks (badly!) that
the Linux HA Stack has been providing for quite a few years.


Yes, Pacemaker needs learning - but not more than any other involved
project, and there are already quite a few here, which have to be known to
any operator or developer already.


(BTW, LINBIT sells training for the Linux HA Cluster Stack - and yes,
I work for them ;)


With all due respect, because I know you come with the best of
intentions but, how is the above related to *anything* in this thread?

Hasn't this thread digressed enough to throw pacemaker in the
discussion just for the sake of it?

I don't mean to come off harsh but seriously, let's stop trying to
save the world in one thread and, instead, let's try to focus on what
the real problem that is being solved is and how we can do it.

The "to DLM or not" discussion was moved to a new thread (renamed from
this one) and this one should be used to discussed *cinder specific
issues* and hopefully come up with a solution - that Gorka has already
proposed - that would provide a better story for Cinder in the short
future.

Flavio

--
@flaper87
Flavio Percoco


pgpkN153_B1FM.pgp
Description: 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] [nova] [FFE] Feature Freeze Exception Request for 'Volume Snapshot Improvements'

[Deepak Shetty]

Hello Nova cores,

I would like to request feature freeze exception for the volume
snapshot improvements
blueprint [1]

This bp was proposed in Juno, but could not be implemented then, hence
was pushed to Liberty, and the patches [2] for the same have been on review
for the last 2+ months and are in good shape AFAICT.

This helps improve the support for online volume snapshots (CInder <-->
Nova flows) and will be useful for anyone in Cinder that use hypervisor
assisted snapshots. Eg: Glusterfs, NFS, Scality et.al. I didn't agree to it
being 'low' priority, but didn't debate against it as I was already in
implementation phase and didn't knew that 'low' would matter! Lesson learnt
for me :)

This patch is pre-req for the Cinder side of volume snapshot
improvements (BP @ [3], patches @ [4]) which is 'Medium' Priority and the
cinder side of patches are in reasonable shape too. I have been working on
all the review comments there on a timely basis and I hope to get the
CInder side of things merged in Liberty as well, which won't be possible if
Nova patches aren't in :(( since Nova is a dep for Cinder patches.

Worst case, even if Cinder patches are not merged, Nova patches are
written with Cinder backward compability in mind, so Nova should work
seamlessly with old Cinder.

Thus i request the Nova cores to grant me FFE. Thanks in advance.

thanx,
deepak

[1]:
https://blueprints.launchpad.net/nova/+spec/volume-snapshot-improvements
[2]:
https://review.openstack.org/#/q/topic:bp/volume-snapshot-improvements,n,z

[3]:
https://blueprints.launchpad.net/cinder/+spec/assisted-snapshot-improvements
[4]:
https://review.openstack.org/#/q/topic:bp/assisted-snapshot-improvements,n,z

[5]: https://review.openstack.org/#/c/165393/
__
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] A possible solution for HA Active-Active

[Fox, Kevin M]

Its been explained for Cinder, but not for other OpenStack projects that also 
have needs in this area.

Thanks,
Kevin


From: Gorka Eguileor
Sent: Tuesday, August 04, 2015 1:39:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] A possible solution for HA Active-Active

On Mon, Aug 03, 2015 at 06:12:23PM +, Fox, Kevin M wrote:
> For example, to parallel the conversation with databases:
>
> "We want a database". Well, that means mongodb, postgres, mysql, berkeleydb, 
> etc
>
> "Oh, well, I need it to be a relational db", Well, that means postgresq, 
> mysql, etc
>
> "Oh, and I need recursive queries"... that excludes even more.
>
> We are pretty sure "We want a distributed lock manager". What problems are we 
> trying to solve using it, and what features do they require in the DLM/DLM 
> Abstraction of choice? That will exclude some of them. It also may exclude 
> abstraction layers that don't expose the features needed. (Recursive queries 
> for example)
>
> Thanks,
> Kevin
> 

Kevin all that has already been explained:

http://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/
http://gorka.eguileor.com/simpler-road-to-cinder-active-active/

As well as on IRC and this thread, I don't see the point of repeating it
over and over again, at some point people need to start doing their
homework and read what's already been said to get up to speed on the
topic so we can move on.

Gorka.

> From: Gorka Eguileor [gegui...@redhat.com]
> Sent: Monday, August 03, 2015 10:48 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] A possible solution for   HA  
> Active-Active
>
> On Mon, Aug 03, 2015 at 03:42:48PM +, Fox, Kevin M wrote:
> > I'm usually for abstraction layers, but they don't always pay off very well 
> > due to catering to the lowest common denominator.
> >
> > Lets clearly define the problem space first. IFF the problem space can be 
> > fully implemented using Tooz, then lets do that. Then the operator can 
> > choose. If Tooz cant and wont handle the problem space, then we're trying 
> > to fit a square peg in a round hole.
>
> What do you mean with clearly define the problem space?  We know what we
> want, we just need to agree on the compromises we are willing to make,
> use a DLM and make admins' life a little harder (only for those that
> deploy A-A) but have an A-A solution earlier, or postpone A-A
> functionality but make their life easier.
>
> And we already know that Tooz is not the Holy Grail and will not perform
> the miracle of giving Cinder HA A-A.  It is only a piece of the problem,
> so there's nothing to discuss there, and it's not a square peg on a
> round hole, because it fits perfectly for what it is intended. But once
> you have filled that square hole you need another peg, the round one for
> the round hole.
>
> If people are expecting to find one thing that fixes everything and
> gives us HA A-A on its own, then I believe they are a little bit lost.
>
> Gorka.
>
> >
> > Thanks,
> > Kevin
> > 
> > From: Gorka Eguileor [gegui...@redhat.com]
> > Sent: Monday, August 03, 2015 1:43 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
> > Active-Active
> >
> > On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> > > Flavio Percoco wrote:
> > > > [...]
> > > > So, to summarize, I love the effort behind this. But, as others have
> > > > mentioned, I'd like us to take a step back, run this accross teams and
> > > > come up with an opinonated solution that would work for everyone.
> > > >
> > > > Starting this discussion now would allow us to prepare enough material
> > > > to reach an agreement in Tokyo and work on a single solution for
> > > > Mikata. This sounds like a good topic for a cross-project session.
> > >
> > > +1
> > >
> > > The last thing we want is to rush a solution that would only solve a
> > > particular project use case. Personally I'd like us to pick the simplest
> > > solution that can solve most of the use cases. Each of the solutions
> > > bring something to the table -- Zookeeper is mature, Consul is
> > > featureful, etcd is lean and simple... Let's not dive into the best
> > > solution but clearly define the problem space first.
> > >
> > > --
> > > Thierry Carrez (ttx)
> > >
> >
> > I don't see those as different solutions from the point of view of
> > Cinder, they are different implementations to the same solution case,
> > using a DLM to lock resources.
> >
> > We keep circling back to the fancy names like moths to a flame, when we
> > are still discussing whether we need or want a DLM for the solution.  I
> > think we should stop doing that, we need to decide on the solution from
> > an abstract point of view (l

[openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

in feature/qos, we use ml2 extension drivers to handle additional
qos_policy_id field that can be provided thru API:

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
/extensions/qos.py?h=feature/qos

What we do in qos extension is we create a database 'binding' object
between the updated port and the QoS policy that corresponds to
qos_policy_id. So we access the database. It means there may be some
complications there, f.e. the policy object is not available for the
tenant, or just does not exist. In that case, we raise an exception
from the extension, assuming that ml2 will propagate it to the user in
some form.

But it does not work. This is because _call_on_ext_drivers swallows
exceptions:

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
/managers.py#n766

It makes me ask some questions:

- - first, do we use extensions as was expected? Can we extend
extensions to cover our use case?

- - second, what would be the right way to go assuming we want to
support the case? Should we just reraise? Or maybe postpone till all
extension drivers are called, and then propagate an exception top into
the stack? (Probably some extension manager specific exception?) Or
maybe we want extensions to claim whether they may raise, and handle
them accordingly?

- - alternatively, if we abuse the API and should stop doing it, which
other options do we have to achieve similar behaviour without relying
on ml2 extensions AND without polluting ml2 driver with qos specific cod
e?

Thanks for your answers,
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz
tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw
BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF
kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq
HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV
psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=
=Fo++
-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] [nova] Thoughts on things that don't make freeze cutoffs

[John Garbutt]

On 3 August 2015 at 20:44, Jesse Cook  wrote:
> On 7/29/15, 2:13 PM, "Matt Riedemann"  wrote:
>>We talked a bit about this at the nova mid-cycle last week but I can't
>>say I completely remember all of the points made, since I feel like we
>>talked ourselves into a circle that got us back to more or less 'the
>>current specs and freeze process is the least of all evils so let's not
>>change it'.
>>
>>Tomorrow is the feature freeze for nova but there is interest from a few
>>people in getting rbd snapshot support into liberty.  The code is up for
>>review [1] but the spec is not approved [2].
>>
>>With the process we have in place we can basically -2 this and say
>>re-propose it for mitaka.
>>
>>One thing mentioned at the mid-cycle was what if people reviewed the
>>spec and approved it, but marked the blueprint for 'next' so it's not
>>actually tracked for liberty, but if the blueprint is approved and
>>people are willing to review the code, it could land in liberty.
>>
>>The obvious downside here is the review burden, we have freeze deadlines
>>in place to avoid a continual demand for feature review when we have
>>bugs to fix before we release.  And it's not fair to the other people
>
> Feel free to throw things at me, but is the primary responsibility of a
> core reviewer to review things or fix things?

I think matt was talking about having time to review all the bug fixes
that are currently waiting for review.

The problem at hand, is getting reviews on the bug fixes and priority
features, its not trying to give core reviewers time to write code.

> Horizontal scaling requires more reviewing.

+1

I really think we need to see more reviews from those outside nova-core.
Without that, its really hard to find the people to grow the nova-core team.

Please see my reasons for that approach:
* 
https://wiki.openstack.org/wiki/Nova/Mentoring#Why_do_code_reviews_if_I_am_not_in_nova-core.3F
* 
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_can_I_get_my_code_merged_faster.3F

> I like to imagine a world where core reviewers mentor and
> review and the rest community writes most of the code.
> I assumed that was part of the implicit contract of becoming
> a core reviewer.

I would prefer a world were most of the code and reviews come from
people outside of nova-core. It should be normal for a code to ready
when a core reviewer gets to do a final check. It just doesn't feel
that way right now. Some subteams are starting to do that, but I would
like to see them all step up to review each others code more (in
public, in gerrit), as a starting point.

Personally I find a mix of coding and reviewing good to keep a decent
level of empathy and sanity. I don't have time for any coding this
release (only a bit of documenting), and its not something I can
honestly recommend as a best practice. If people don't maintain a good
level of reviews, we do tend to drop those folks from nova-core.

I know ttx has been pushing for dedicated reviewers. It would be nice
to find folks that can do that, but we just haven't found any of those
people to date.

> One alternative solution is to make core reviewers for specs a different set
> (intersection is acceptable) of people that spend even less time writing code.

Thats what we have today, nova-specs-core.

The problem we are facing right now, is having enough folks to review
all the code for all the specs and blueprints we have already approved
(I think it was just over 100 blueprints for liberty, at its peak),
with out affecting merging high priority bug fixes and all the
priority features. I am trying to ignore the around 100 pending specs
we haven't managed to get merged for liberty, but there is a very
similar problem there.

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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Thierry Carrez]

Clark Boylan wrote:
> On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
>> In order to make this work, it looks like we'd require:
>>
>> * pbr changes so that it supports a mode where every commit on the
>> branch increments .Z
>>
>> * infra changes to automatically push the corresponding tag when the
>> commit is merged
>>
>> To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80
>> (kilo) and Nova 10.0.218 (juno).
>
> I am not a fan of doing this second option at all. We would be polluting
> the ref space of our repos with redundant information making the output
> of `git tag` unusable to humans. If this was not redundant info and a
> tag of 11.0.80 provided more information than a generated version of
> 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.

I tend to agree that pushing a tag per commit would end up being very
noisy. I think the main problem we are trying to solve is to be able to
map version numbers to git commits. A security fix might be introduced
at 11.0.73 so being able to see that whatever you get is "past that" is
useful.

There are two ways of avoiding massive tag pollution: not using tags to
solve the above problem (but lifeless said it was the only sensible
route), or doing on-demand tagging rather than automatic tagging.

>> [...]
>> If we can't figure out a way to make this work (or we decide it was
>> actually insane), the backup plan is to move to each project releasing
>> stable branch versions from time to time by manually requesting a
>> 12.0.1, 12.0.2... tag when they feel like it. The benefit of this
>> approach is that it matches what we do for libraries. The drawback is
>> that it requires project teams to pay more attention to stable branches.
>
> I wonder why that is a drawback? I am not heavily involved in stable
> branch support but it seems like this is a reasonable expectation to
> have of projects and would result in better stable releases overall?
> This backup plan seems reasonable enough to be considered as a first
> plan option too.

So the trick here is that you still want them frequently released, so
that they can serve as reference points. That means every month or so,
someone in a project team will need to care. I'm not saying it would be
a bad thing, I'm just saying that in the past, nobody had to care. So
with this option, the release liaison role (often currently served, by
default, by the PTL) gets busier.

-- 
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] [stable] [infra] How to auto-generate stable release notes

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Robert Collins's message of 2015-08-04 06:43:48 +1200:
>> On 4 August 2015 at 02:46, Alexis Lee  wrote:
>>> Whichever solution we pick - should we also adopt it on master? Naively
>>> it sounds useful to be able to generate release notes for master too.
>>> And this avoids inconsistency between master and stable beyond that
>>> required to rebase.
>>>
>>> Explanations of the many ways I'm wrong are always appreciated.
>>
>> I think you're right on.
>>
>> Something with the same process as ChangeLog generation today - read
>> from git, process, output document - will be much less fragile for
>> merges.
> 
> We could use the same convention for highlighting changes in libraries,
> and pull the messages out for the release announcements.

Right, the key difference between release notes and changelogs is that
release notes are a curated set of significant highlights.

> How detailed do we want release notes to be? For example, do we need to
> worry about supporting multiple paragraphs or ASCII art or anything like
> that?

Looking at our current release notes, they are a set of bullet points of
a pre-determined type. Types vary slightly between master and stable:

Master release notes (https://wiki.openstack.org/wiki/ReleaseNotes/Kilo)
currently contain three/four sections:

* Key new features
* Known issues
* Upgrade notes
* (Other notes)

[ "Known issues" are generally used to list known bugs that we didn't
have time to fix (or couldn't find a good fix for) at release time. So
there is no related commit. How would we push those ? ]

Stable release notes
(https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.1) currently list:

* (Upgrade notes) -- hopefully never needed
* Security fixes
* Bugs fixed (just links to Launchpad lists)

To answer your question, I don't think we need to support complex
entries with multiple paragraphs or ascii art: single bullet points are
probably enough. A simple grammar of predetermined headers should do the
trick.

We also might need a mechanism to add to release notes when we realize
after the fact that a specific commit in past history warrants a
highlight. Would some kind of no-change commit do the trick ?

-- 
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] [Fuel] SSL for master node API

[Stanislaw Bogatkin]

Hi guys,
in overall movement of Fuel to use secure sockets we think about wrapping
master node UI and API calls to SSL. But there are next caveat:

a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
little. But if it will be rewritten in 7.0 and HTTPS on master node will be
forced by default, it will break upgrade from previous releases to 7.0 due
fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
default and fuel-nailgun-agent on all environments won't upgraded, so it
won't be able to connect to master node after upgrade. It breaks seamless
upgrade procedure.

What options I see there:
1. We can forcedly enable SSL for master node and rewrite clients in 7.0 to
be able to work over it. In release notes for 7.0 we will write forewarning
that clients which want to upgrade master node from previous releases to
7.0 must also install new fuel-nailgun-agent to all nodes in all deployed
environments.

2. We can have both SSL and non-SSL versions enabled by default and rewrite
fuel-nailgun-client in 7.0 such way that it will check SSL availability and
be able to work in plain HTTP for legacy mode. So, for all new environments
SSL will be used by default and for old ones plain HTTP will continue to
work too. Master node upgrade will not be broken in this case.

3. We can do some mixed way by gradually rewrite fuel-nailgun-client, save
both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
releases. It is just postponed version of first clause, so it doesn't seems
valid for me, actually.

I would be really glad to hear what you think about this. Thank you in
advance.
__
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] [Keystone] [Horizon] Attribute Mapping GUI for Horizon

[Ioram Schechtman Sette]

Hi Marek,

Done. ;)

Regards,
Ioram


2015-08-03 8:07 GMT+01:00 Marek Denis :

> Hi Ioram,
>
> How about moving this discussion to the mailing list? Maybe others will
> find it useful too.
>
> cheers,
> Marek
>
> On 02.08.2015 11:28, Ioram Schechtman Sette wrote:
>
>> Hi Marek, hi all,
>>
>> Just to complement, I thought in some cases that I don't know how they
>> are handled by the mapping engine.
>>
>> For instance:
>>
>>  - Remote attribute "a1" with value "v1" maps to domain/user "D1/U1"
>>  - Remote attribute "a2" with value "v2" maps to domain/user "D1/U2"
>>
>>  If the remote user has the attributes "a1=v1" and "a2=v2", will he
>> be mapped to D1/U1 or D1/U2?
>>
>> The situation can be repeated for different combinations of local users
>> and groups.
>>
>> Using the super set (union) of the privileges of D1/U1 and D1/U2 to the
>> remote user, I think it solves the problem.
>> According to this reasoning, the expression "local": {"user": {"name":
>> "{0}"}} will mean that we will search for a local user whose name
>> matches the remote user id in order to get its privileges.
>> The set of privileges can be increased if other mapping rules also
>> matches to other users or groups.
>>
>> Regards,
>> Ioram
>>
>>
>> 2015-07-30 17:32 GMT+01:00 David Chadwick > >:
>>
>>
>> Hi Marek
>>
>> Thanks for the clear exposition.
>>
>> To answer your question Why are you interested in such a feature? is
>> that it seemed to be the logical thing to do. A user is identified by
>> a
>> set of identity attributes (by the IdP) and these are mapped into
>> permission by mapping rules. I assume the admin who sets up the
>> mapping
>> rules knows what he is doing, and if he wants a remote user to have
>> the
>> privileges of a local user plus some more, then the easiest way to do
>> this would be to map into one or more groups plus the local user.
>>
>> Since the same thing can be achieved by creating a new group
>> equivalent
>> to the local user, and mapping the remote user into all of these
>> groups,
>> then why downgrade the most logical (and easiest) way of achieving the
>> same ultimate objective?
>>
>> regards
>>
>> David
>>
>>
>> On 30/07/2015 11:26, Marek Denis wrote:
>>  > Hi David,
>>  >
>>  > On 29.07.2015 18:59, David Chadwick wrote:
>>  >
>>  >> this is very helpful thanks, and it answers our question.
>>  >>
>>  >> So to summarise, you can map a federated user into multiple
>> groups, or
>>  >> into an existing local user/domain, but not into both, since the
>> latter
>>  >> will override the former and the groups will be discarded. Was
>> this
>>  >> behaviour actually discussed anywhere? ie. why cannot a
>> federated user
>>  >> have a superset of the permissions of a local user and some
>> additional
>>  >> groups?
>>  >
>>  > Well, it was mostly discussed at one of the Keystone midcycles, I
>> think
>>  > the one in January. The spec for this (along with new keyword
>>  > 'whitelist' and 'blacklist') can be found here:
>>  >
>>
>> https://github.com/openstack/keystone-specs/blob/master/specs/kilo/federated-direct-user-mapping.rst
>>  >
>>  >
>>  > And to answer your question "why a federated user cannot have a
>> superset
>>  > of the permissions of a local user and some extras" is probably
>> because
>>  > we wanted to simply leverage authentication to IdP, not create any
>>  > superpower user. Also, it is because the returned identity is
>> 'existing
>>  > user', with her/his id, set of role assignments on a
>> project/domain. I
>>  > am not sure it's good to be able to dynamically upgrade average
>> users -
>>  > if so, i'd rather make 'ephemeral users with all the role
>> assignments
>>  > equal to user X'.
>>  > Why are you interested in such a feature? We can probably discuss
>> it on
>>  > a ML as Morgan suggested and
>>  >
>>  >
>>  >> On 29/07/2015 15:01, Marek Denis wrote:
>>  >>> Hi David, all,
>>  >>>
>>  >>> Thanks for your e-mail.
>>  >>> I will quickly respond to your question about mapping rules.
>>  >>>
>>  >>> Currently we can map to either ephemeral user (who is dynamically
>>  >>> assigned some group memberships) as well as existing user.
>>  >>> For the latter you need to specify a mapping rule a user_id and
>> an
>>  >>> existing domain.
>>  >>> Currently there is a service domain called 'Federated' and
>> ephemeral
>>  >>> users are members of that one.
>>  >>>
>>  >>> So for mapping to existing users you should build your rule like:
>>  >>>
>>  >>> user: {
>>  >>>  "id": "madenis"
>>  >>>  "domain": {
>>  >>>  "name": "CERN"
>>  >>>  }
>>  >>> }
>>  >>>
>>  >>> Mapping engine will see the domain 

Re: [openstack-dev] [Keystone] [Horizon] UI for Keystone dynamic policies editing

[David Chadwick]

Hi All

Ioram has built a complete set of wireframe policy GUI screens for
comment. He has uploaded them to InVision

https://openstack.invisionapp.com/share/HQ3QN2123#/screens

Please comment on these in InVision

regards

David

On 03/08/2015 21:39, Lin Hua Cheng wrote:
> Hi Timur,
> 
> Thanks for bringing this up. 
> 
> I think we can borrow some concept from the Mistral Workbook Builder. I
> like the ability to add items and seeing the preview on the right side.
> We can re-use that part.
> 
> The challenging part would be building a Rule expression builder that
> supports the policy semantic [1] [2]. We should start with creating some
> mockups.  The builder will also be useful even if we don't land the
> dynamic policy in L by adding support of loading local policy files for
> editing and providing export functionality.
> 
> I imagine there would be a pop-up that will allow user to build the
> expression with support for:
> 1. Building nested expression using AND OR and ()
> 2. Auto-complete that lists:
> -  existing rule definition 
> -  available context variable (like domain_id, user_id, target.token)
> 
> Just throwing some ideas around.  
> 
> This is a good opportunity to engage the new UX project they might have
> a better idea how the Expression Builder should look like. :)
> 
> Thanks,
> Lin
> 
> [1]
> https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L18-L210
> [2]
> http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html
> 
> 
> On Mon, Aug 3, 2015 at 5:10 AM, Timur Sufiev  > wrote:
> 
> Hello, folks!
> 
> A word has come to me that on the recent Keystone mid-cycle summit
> dynamic policies have been discussed - as well as the lack of means
> to edit them in UX-friendly manner. I had my own share of editing
> *_policy.json files inside openstack_dashboard/conf and can hardly
> state it's easy. At least, when dynamic policies are fully supported
> by all OpenStack services we will have no longer to edit the same
> files on every controller node in case of HA installations. Still,
> the problem of editing a single policy file remains. AFAIK, the
> obscurity of policy rules' format had lead may deployers to the
> copy-pasting existing rules with minimal changes - when they were
> meant to a flexible tool for RBAC definitions.
> 
> But I wouldn't write this letter, if I didn't have some kind of
> solution to the task of editing the policies. During my work on
> Merlin framework/Mistral Workbook Builder I've achieved some results
> that might be useful for a Keystone community. More specifically,
> visual structure and type of relations between Workbook entities
> appeared to me to be similar to the entities of Keystone policies.
> Understanding that some things are better seen in dynamic than in
> static screenshots, I'm sharing the address of the VM where the
> Workbook builder is deployed inside
> Horizon: http://horizon-merlin.mirantis.com/horizon/project/
> Credentials are demo/demo. Some features like saving the workbooks
> to db or the rest OpenStack control plane are disabled for security
> reasons, leaving only the Workbook Builder UI there. 
> 
> I'd like to start the discussion about the extent of reusing Merlin
> UI elements for making a dynamic policies editor.
> 
> __
> 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] [Fuel] SSL for master node API

[Evgeniy L]

Hi,

+1 to 2nd solution, in this case old environments will work without
additional
actions. Agents for new environments, CLI and UI will use SSL.
But probably for UI we will have to perform redirect on JS level.

Thanks,

On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin 
wrote:

> Hi guys,
> in overall movement of Fuel to use secure sockets we think about wrapping
> master node UI and API calls to SSL. But there are next caveat:
>
> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
> little. But if it will be rewritten in 7.0 and HTTPS on master node will be
> forced by default, it will break upgrade from previous releases to 7.0 due
> fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
> default and fuel-nailgun-agent on all environments won't upgraded, so it
> won't be able to connect to master node after upgrade. It breaks seamless
> upgrade procedure.
>
> What options I see there:
> 1. We can forcedly enable SSL for master node and rewrite clients in 7.0
> to be able to work over it. In release notes for 7.0 we will write
> forewarning that clients which want to upgrade master node from previous
> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
> all deployed environments.
>
> 2. We can have both SSL and non-SSL versions enabled by default and
> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
> availability and be able to work in plain HTTP for legacy mode. So, for all
> new environments SSL will be used by default and for old ones plain HTTP
> will continue to work too. Master node upgrade will not be broken in this
> case.
>
> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client, save
> both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
> releases. It is just postponed version of first clause, so it doesn't seems
> valid for me, actually.
>
> I would be really glad to hear what you think about this. Thank you in
> advance.
>
> __
> 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] [nova] Thoughts on things that don't make freeze cutoffs

[Thierry Carrez]

John Garbutt wrote:
> [...]
> Personally I find a mix of coding and reviewing good to keep a decent
> level of empathy and sanity. I don't have time for any coding this
> release (only a bit of documenting), and its not something I can
> honestly recommend as a best practice. If people don't maintain a good
> level of reviews, we do tend to drop those folks from nova-core.
> 
> I know ttx has been pushing for dedicated reviewers. It would be nice
> to find folks that can do that, but we just haven't found any of those
> people to date.

Hell no! I'd hate dedicated reviewers.

I want everyone to be a reviewer and a commit author. It's the only way
to keep current on the code and relevant enough to be trusted for the
final +2s.

The trick is that given how wide and diverse Nova's code is, it's
impossible to be a reviewer / commit author / expert in all the Nova
things. If you slowly grew with Nova over the past years, you may have a
good grasp of most parts. But for newcomers, it's an impossible mountain
to climb, and they prefer to go to smaller projects. And as we burn out
old people with a giant set of reviews, we fail to replace them with new
blood.

This is why I advocate dividing code / reviewers / expertise along
smaller areas within Nova, so that new people can focus and become a
master again. What I'm pushing for is creating Nova subteams with their
own core reviewers, which would be experts and trusted to +2 on a
defined subset of code.

-- 
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] [python-neutronclient][neutron] sub-project client extensions

[Fawad Khaliq]

Folks,

In networking-plumgrid project, we intend to implement client side for some
of the vendor specific extensions. Looking at the current implementation
for client side for some vendors, I see the code is part of
python-neutronclient tree [1]. I do see this change [2] talking about a way
to load extensions through entry points, however, I could not find any
example extension module.

Has anyone gone through the route of implementing out of tree extensions
for Neutron client, which extend python-neutronclient shell and load at
run/install time? With decomposition phase II, it makes sense to keep the
client side in the respective projects as well.

[1]
https://github.com/openstack/python-neutronclient/tree/master/neutronclient/neutron/v2_0
[2] https://review.openstack.org/#/c/148318/16

Thanks,
Fawad Khaliq
__
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] [nova] Thoughts on things that don't make freeze cutoffs

[Davanum Srinivas]

+1 to "pushing for is creating Nova subteams with their own core
reviewers, which would be experts and trusted to +2 on a defined
subset of code."

Oslo has cores who can +2 any of the oslo libraries and each Oslo
library has its own cores as well. We tend to elevate karma quickly
for cores between libraries and from library core to the main core. So
this is working well and could be something Nova can adopt. (oslo
library == nova sub team).

I used to think that subteam +2 karma with informal boundaries may be
better, but nova cores may be more comfortable with explicit
boundaries and karma elevation.

...But anything is better than status quo!

Thanks,
dims


On Tue, Aug 4, 2015 at 6:54 AM, Thierry Carrez  wrote:
> John Garbutt wrote:
>> [...]
>> Personally I find a mix of coding and reviewing good to keep a decent
>> level of empathy and sanity. I don't have time for any coding this
>> release (only a bit of documenting), and its not something I can
>> honestly recommend as a best practice. If people don't maintain a good
>> level of reviews, we do tend to drop those folks from nova-core.
>>
>> I know ttx has been pushing for dedicated reviewers. It would be nice
>> to find folks that can do that, but we just haven't found any of those
>> people to date.
>
> Hell no! I'd hate dedicated reviewers.
>
> I want everyone to be a reviewer and a commit author. It's the only way
> to keep current on the code and relevant enough to be trusted for the
> final +2s.
>
> The trick is that given how wide and diverse Nova's code is, it's
> impossible to be a reviewer / commit author / expert in all the Nova
> things. If you slowly grew with Nova over the past years, you may have a
> good grasp of most parts. But for newcomers, it's an impossible mountain
> to climb, and they prefer to go to smaller projects. And as we burn out
> old people with a giant set of reviews, we fail to replace them with new
> blood.
>
> This is why I advocate dividing code / reviewers / expertise along
> smaller areas within Nova, so that new people can focus and become a
> master again. What I'm pushing for is creating Nova subteams with their
> own core reviewers, which would be experts and trusted to +2 on a
> defined subset of code.
>
> --
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] API for getting connection info from console token

[Radoslav Gerganov]

There is an API (os-console-auth-tokens) which returns the connection 
info which correspond to a given console token.  However this API works 
only for RDP consoles:


https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/console_auth_tokens.py#L49

Why do we have this restriction?  We need the same API for MKS consoles 
as well.  I have posted the following patch:


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

but I'd prefer to remove the type check altogether and make it work for 
all types of consoles.  I don't see any reason to restrict the API only 
for certain types of VM consoles.  What do you think?


Thanks,
Rado

__
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] SSL for master node API

[Vladimir Kuklin]

I am for 2nd option for 7.0 and for 3rd for 8.0

But I would suggest that we add an option to astute.yaml that a user can
set to true to force ssl and then he will need to install updated
nailgun-agent for older environments. In this case user will do this
concisely, knowing about potential caveats of forcing SSL.

On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:

> Hi,
>
> +1 to 2nd solution, in this case old environments will work without
> additional
> actions. Agents for new environments, CLI and UI will use SSL.
> But probably for UI we will have to perform redirect on JS level.
>
> Thanks,
>
> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin  > wrote:
>
>> Hi guys,
>> in overall movement of Fuel to use secure sockets we think about wrapping
>> master node UI and API calls to SSL. But there are next caveat:
>>
>> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
>> little. But if it will be rewritten in 7.0 and HTTPS on master node will be
>> forced by default, it will break upgrade from previous releases to 7.0 due
>> fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
>> default and fuel-nailgun-agent on all environments won't upgraded, so it
>> won't be able to connect to master node after upgrade. It breaks seamless
>> upgrade procedure.
>>
>> What options I see there:
>> 1. We can forcedly enable SSL for master node and rewrite clients in 7.0
>> to be able to work over it. In release notes for 7.0 we will write
>> forewarning that clients which want to upgrade master node from previous
>> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
>> all deployed environments.
>>
>> 2. We can have both SSL and non-SSL versions enabled by default and
>> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
>> availability and be able to work in plain HTTP for legacy mode. So, for all
>> new environments SSL will be used by default and for old ones plain HTTP
>> will continue to work too. Master node upgrade will not be broken in this
>> case.
>>
>> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
>> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
>> releases. It is just postponed version of first clause, so it doesn't seems
>> valid for me, actually.
>>
>> I would be really glad to hear what you think about this. Thank you in
>> advance.
>>
>> __
>> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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] [puppet] Move to rspec-puppet 2.2.0

[Sebastien Badia]

On Tue, Jun 09, 2015 at 12:38:55PM (-0700), Cody Herriges wrote:
> Seemingly simple proposition of moving from rspec-puppet 2.1.0 to 2.2.0
> so as to address the issue of helper library loading that is shipped as
> part of a few of our modules.  In my specific case, puppet-vswitch's
> puppetx library directory and its use by puppet-neutron.  This is part
> of the effort to get all the modules passing tests on Puppet 4.
> 
> The upstream rspec-puppet commit:
> https://github.com/rodjek/rspec-puppet/commit/d4278834d5236deb497b84fbd937bc33e6a717a3
> 
> puppet-modulesync-configs: https://review.openstack.org/189886
> 
> I already shipped for review, a msync based update to all managed module
> based on the above review on puppet-modulesync-configs.  If there are no
> objections to this, I'll clean up them and get them passing.  In the
> mean time I'll go through and just mark them all WIP.

Hi Cody!

Sorry for the delay… And even if it seems to be more complicated than expected
to have msync integrated with infra¹, it's maybe the time to run our initial
sync for our puppet modules.

I've an action about that, according the latest meeting², but you already have a
couple of patchs for this initial sync, can I use and update your patchs³?

Seb

¹http://lists.openstack.org/pipermail/openstack-dev/2015-July/071036.html
²http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-28-15.00.html
³https://review.openstack.org/#/q/status:open+branch:master+topic:msync_rspec_version,n,z

-- 
Sebastien Badia


signature.asc
Description: 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] [Fuel] SSL for master node API

[Vladimir Sharshov]

Hi,

+1 to 2nd solution too.

On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:

> Hi,
>
> +1 to 2nd solution, in this case old environments will work without
> additional
> actions. Agents for new environments, CLI and UI will use SSL.
> But probably for UI we will have to perform redirect on JS level.
>
> Thanks,
>
> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin  > wrote:
>
>> Hi guys,
>> in overall movement of Fuel to use secure sockets we think about wrapping
>> master node UI and API calls to SSL. But there are next caveat:
>>
>> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
>> little. But if it will be rewritten in 7.0 and HTTPS on master node will be
>> forced by default, it will break upgrade from previous releases to 7.0 due
>> fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
>> default and fuel-nailgun-agent on all environments won't upgraded, so it
>> won't be able to connect to master node after upgrade. It breaks seamless
>> upgrade procedure.
>>
>> What options I see there:
>> 1. We can forcedly enable SSL for master node and rewrite clients in 7.0
>> to be able to work over it. In release notes for 7.0 we will write
>> forewarning that clients which want to upgrade master node from previous
>> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
>> all deployed environments.
>>
>> 2. We can have both SSL and non-SSL versions enabled by default and
>> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
>> availability and be able to work in plain HTTP for legacy mode. So, for all
>> new environments SSL will be used by default and for old ones plain HTTP
>> will continue to work too. Master node upgrade will not be broken in this
>> case.
>>
>> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
>> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
>> releases. It is just postponed version of first clause, so it doesn't seems
>> valid for me, actually.
>>
>> I would be really glad to hear what you think about this. Thank you in
>> advance.
>>
>> __
>> 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] [Fuel] SSL for master node API

[Sheena Gregson]

+1 to #2



*From:* Vladimir Kuklin [mailto:vkuk...@mirantis.com]
*Sent:* Tuesday, August 04, 2015 6:25 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] SSL for master node API



I am for 2nd option for 7.0 and for 3rd for 8.0



But I would suggest that we add an option to astute.yaml that a user can
set to true to force ssl and then he will need to install updated
nailgun-agent for older environments. In this case user will do this
concisely, knowing about potential caveats of forcing SSL.



On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:

Hi,



+1 to 2nd solution, in this case old environments will work without
additional

actions. Agents for new environments, CLI and UI will use SSL.

But probably for UI we will have to perform redirect on JS level.



Thanks,



On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin 
wrote:

Hi guys,

in overall movement of Fuel to use secure sockets we think about wrapping
master node UI and API calls to SSL. But there are next caveat:



a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
little. But if it will be rewritten in 7.0 and HTTPS on master node will be
forced by default, it will break upgrade from previous releases to 7.0 due
fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
default and fuel-nailgun-agent on all environments won't upgraded, so it
won't be able to connect to master node after upgrade. It breaks seamless
upgrade procedure.



What options I see there:

1. We can forcedly enable SSL for master node and rewrite clients in 7.0 to
be able to work over it. In release notes for 7.0 we will write forewarning
that clients which want to upgrade master node from previous releases to
7.0 must also install new fuel-nailgun-agent to all nodes in all deployed
environments.



2. We can have both SSL and non-SSL versions enabled by default and rewrite
fuel-nailgun-client in 7.0 such way that it will check SSL availability and
be able to work in plain HTTP for legacy mode. So, for all new environments
SSL will be used by default and for old ones plain HTTP will continue to
work too. Master node upgrade will not be broken in this case.



3. We can do some mixed way by gradually rewrite fuel-nailgun-client, save
both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
releases. It is just postponed version of first clause, so it doesn't seems
valid for me, actually.



I would be really glad to hear what you think about this. Thank you in
advance.



__
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





-- 

Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.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] [Keystone] [Horizon] UI for Keystone dynamic policies editing

[Ioram Schechtman Sette]

Hi All,

The correct link is:
https://openstack.invisionapp.com/share/9Z3RI8OD7#/screens

Regards,
Ioram

2015-08-04 11:42 GMT+01:00 David Chadwick :

> Hi All
>
> Ioram has built a complete set of wireframe policy GUI screens for
> comment. He has uploaded them to InVision
>
> https://openstack.invisionapp.com/share/HQ3QN2123#/screens
>
> Please comment on these in InVision
>
> regards
>
> David
>
> On 03/08/2015 21:39, Lin Hua Cheng wrote:
> > Hi Timur,
> >
> > Thanks for bringing this up.
> >
> > I think we can borrow some concept from the Mistral Workbook Builder. I
> > like the ability to add items and seeing the preview on the right side.
> > We can re-use that part.
> >
> > The challenging part would be building a Rule expression builder that
> > supports the policy semantic [1] [2]. We should start with creating some
> > mockups.  The builder will also be useful even if we don't land the
> > dynamic policy in L by adding support of loading local policy files for
> > editing and providing export functionality.
> >
> > I imagine there would be a pop-up that will allow user to build the
> > expression with support for:
> > 1. Building nested expression using AND OR and ()
> > 2. Auto-complete that lists:
> > -  existing rule definition
> > -  available context variable (like domain_id, user_id, target.token)
> >
> > Just throwing some ideas around.
> >
> > This is a good opportunity to engage the new UX project they might have
> > a better idea how the Expression Builder should look like. :)
> >
> > Thanks,
> > Lin
> >
> > [1]
> >
> https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L18-L210
> > [2]
> >
> http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html
> >
> >
> > On Mon, Aug 3, 2015 at 5:10 AM, Timur Sufiev  > > wrote:
> >
> > Hello, folks!
> >
> > A word has come to me that on the recent Keystone mid-cycle summit
> > dynamic policies have been discussed - as well as the lack of means
> > to edit them in UX-friendly manner. I had my own share of editing
> > *_policy.json files inside openstack_dashboard/conf and can hardly
> > state it's easy. At least, when dynamic policies are fully supported
> > by all OpenStack services we will have no longer to edit the same
> > files on every controller node in case of HA installations. Still,
> > the problem of editing a single policy file remains. AFAIK, the
> > obscurity of policy rules' format had lead may deployers to the
> > copy-pasting existing rules with minimal changes - when they were
> > meant to a flexible tool for RBAC definitions.
> >
> > But I wouldn't write this letter, if I didn't have some kind of
> > solution to the task of editing the policies. During my work on
> > Merlin framework/Mistral Workbook Builder I've achieved some results
> > that might be useful for a Keystone community. More specifically,
> > visual structure and type of relations between Workbook entities
> > appeared to me to be similar to the entities of Keystone policies.
> > Understanding that some things are better seen in dynamic than in
> > static screenshots, I'm sharing the address of the VM where the
> > Workbook builder is deployed inside
> > Horizon: http://horizon-merlin.mirantis.com/horizon/project/
> > Credentials are demo/demo. Some features like saving the workbooks
> > to db or the rest OpenStack control plane are disabled for security
> > reasons, leaving only the Workbook Builder UI there.
> >
> > I'd like to start the discussion about the extent of reusing Merlin
> > UI elements for making a dynamic policies editor.
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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/opens

[openstack-dev] (no subject)

[Mike Kolesnik]

On Tue, Aug 4, 2015 at 1:02 PM, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi all,
>
> in feature/qos, we use ml2 extension drivers to handle additional
> qos_policy_id field that can be provided thru API:
>
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
> /extensions/qos.py?h=feature/qos
>
> What we do in qos extension is we create a database 'binding' object
> between the updated port and the QoS policy that corresponds to
> qos_policy_id. So we access the database. It means there may be some
> complications there, f.e. the policy object is not available for the
> tenant, or just does not exist. In that case, we raise an exception
> from the extension, assuming that ml2 will propagate it to the user in
> some form.
>

​First of all maybe we should be asking this on the u/s mailing list to get
a broader view?
​


>
> But it does not work. This is because _call_on_ext_drivers swallows
> exceptions:
>
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
> /managers.py#n766
>
> It makes me ask some questions:
>
> - - first, do we use extensions as was expected? Can we extend
> extensions to cover our use case?
>

​I think we are, they mostly fit the case but as everything in Neutron it's
unripe.
However from my experience this was the ripest option available to us..
​


>
> - - second, what would be the right way to go assuming we want to
> support the case? Should we just reraise? Or maybe postpone till all
> extension drivers are called, and then propagate an exception top into
> the stack? (Probably some extension manager specific exception?) Or
> maybe we want extensions to claim whether they may raise, and handle
> them accordingly?
>

​I was thinking in order not to alter existing extension behaviours that we
can define in the ML2 extension driver scope a special exception type (sort
of exception container), and if an exception of this type is raised ​then
we should re-raise it.
I'm not sure there's much value to aggregating the exceptions right off the
bat and this can be done later on.



>
> - - alternatively, if we abuse the API and should stop doing it, which
> other options do we have to achieve similar behaviour without relying
> on ml2 extensions AND without polluting ml2 driver with qos specific cod
> e?
>
> Thanks for your answers,
> Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz
> tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw
> BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF
> kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq
> HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV
> psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=
> =Fo++
> -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
>



-- 
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] [neutron][qos][ml2] extensions swallow exceptions

[Mike Kolesnik]

Don't know why subject wasn't set automatically..

On Tue, Aug 4, 2015 at 3:30 PM, Mike Kolesnik  wrote:

>
>
> On Tue, Aug 4, 2015 at 1:02 PM, Ihar Hrachyshka 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi all,
>>
>> in feature/qos, we use ml2 extension drivers to handle additional
>> qos_policy_id field that can be provided thru API:
>>
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
>> /extensions/qos.py?h=feature/qos
>> 
>>
>> What we do in qos extension is we create a database 'binding' object
>> between the updated port and the QoS policy that corresponds to
>> qos_policy_id. So we access the database. It means there may be some
>> complications there, f.e. the policy object is not available for the
>> tenant, or just does not exist. In that case, we raise an exception
>> from the extension, assuming that ml2 will propagate it to the user in
>> some form.
>>
>
> ​First of all maybe we should be asking this on the u/s mailing list to
> get a broader view?
>

Don't mind this, I must be drunk..​


​
>
>
>>
>> But it does not work. This is because _call_on_ext_drivers swallows
>> exceptions:
>>
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
>> /managers.py#n766
>> 
>>
>> It makes me ask some questions:
>>
>> - - first, do we use extensions as was expected? Can we extend
>> extensions to cover our use case?
>>
>
> ​I think we are, they mostly fit the case but as everything in Neutron
> it's unripe.
> However from my experience this was the ripest option available to us..
> ​
>
>
>>
>> - - second, what would be the right way to go assuming we want to
>> support the case? Should we just reraise? Or maybe postpone till all
>> extension drivers are called, and then propagate an exception top into
>> the stack? (Probably some extension manager specific exception?) Or
>> maybe we want extensions to claim whether they may raise, and handle
>> them accordingly?
>>
>
> ​I was thinking in order not to alter existing extension behaviours that
> we can define in the ML2 extension driver scope a special exception type
> (sort of exception container), and if an exception of this type is raised
> ​then we should re-raise it.
> I'm not sure there's much value to aggregating the exceptions right off
> the bat and this can be done later on.
>
>
>
>>
>> - - alternatively, if we abuse the API and should stop doing it, which
>> other options do we have to achieve similar behaviour without relying
>> on ml2 extensions AND without polluting ml2 driver with qos specific cod
>> e?
>>
>> Thanks for your answers,
>> Ihar
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz
>> tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw
>> BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF
>> kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq
>> HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV
>> psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=
>> =Fo++
>> -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
>>
>
>
>
> --
> Regards,
> Mike
>



-- 
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] [designate] and [lbaas] - GSLB API and backend support

[Hayes, Graham]

Sure, we need the other cores to merge it - I cannot merge my own change.

If you are OK with the current version, you can leave a comment on the
pull request, which helps cores decide if the PR is ready.

Thanks,

Graham

On 03/08/15 18:10, Gandhi, Kunal wrote:
> Hi Graham,
> 
> Can we have your GSLB pull request merged to the
> repo https://github.com/gslb/gslb-specs/pull/1/files ? I would like to
> send another pull request based on these changes.
> 
> Regards
> Kunal
> 
> 
>> On Jun 30, 2015, at 8:38 AM, Hayes, Graham > > wrote:
>>
>> I have started to put together a working draft of an API here:
>>
>> https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing
>>
>> I would suggest we skip this weeks meeting, and review this doc, and
>> circle back next week?
>>
>> I have opened it for comment, and I will add anyone who sends on their
>> email to the editors list.
>>
>> Thanks,
>>
>> Graham
>>
>> On 24/06/15 15:16, Samuel Bercovici wrote:
>>> Great!
>>>
>>> Thanks you. I have missed this one.
>>>
>>> *From:*Gandhi, Kunal [mailto:kunalhgan...@gmail.com]
>>> *Sent:* Wednesday, June 24, 2015 12:21 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
>>> backend support
>>>
>>> Hi Sam
>>>
>>> Yes. we discussed the use cases 2 weeks ago on irc. The IRC logs can be
>>> found here
>>> http://eavesdrop.openstack.org/meetings/gslb/2015/gslb.2015-06-09-16.00.log.html
>>>
>>> and the use case document can be found here
>>> https://docs.google.com/document/d/1016shVnPaK8l8HxMpjADiYtY2O94p4g7JxjuIA-qv7w/edit?usp=sharing
>>>
>>> Regards
>>>
>>> Kunal
>>>
>>>On Jun 24, 2015, at 12:35 AM, Samuel Bercovici >>> wrote:
>>>
>>>Hi Kunal,
>>>
>>>Did you also include use cases per our last discussion on IRC?
>>>I prefer to start with use cases before we dive into APIs.
>>>
>>>Thanks,
>>>-Sam.
>>>
>>>
>>>-Original Message-
>>>From: Gandhi, Kunal [mailto:kunalhgan...@gmail.com]
>>>Sent: Wednesday, June 24, 2015 6:47 AM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
>>>backend support
>>>
>>>Hi All,
>>>
>>>I have a very draft for the GSLB API and would like to upload it
>>>somewhere for discussion. What is the best place to upload and
>>>collaborate the draft ? Since the API docs have a lot of JSON
>>>payloads in it, I am not sure whether Google Docs will be
>>>appropriate for that.
>>>
>>>Regards
>>>Kunal
>>>
>>>
>>>On Jun 15, 2015, at 10:03 PM, Doug Wiegley
>>>mailto:doug...@parksidesoftware.com>>
>>>wrote:
>>>
>>>Hi all,
>>>
>>>We don’t have a rough draft API doc yet, so I’m suggesting that we
>>>postpone tomorrow morning’s meeting until next week. Does anyone
>>>have any other agenda items, or want the meeting tomorrow?
>>>
>>>Thanks,
>>>doug
>>>
>>>
>>>
>>>On Jun 2, 2015, at 10:52 AM, Doug Wiegley
>>>mailto:doug...@parksidesoftware.com>>
>>>wrote:
>>>
>>>Hi all,
>>>
>>>The initial meeting logs can be found at
>>>http://eavesdrop.openstack.org/meetings/gslb/2015/ , and we will be
>>>having another meeting next week, same time, same channel.
>>>
>>>Thanks,
>>>doug
>>>
>>>
>>>
>>>On May 31, 2015, at 1:27 AM, Samuel Bercovici >>> wrote:
>>>
>>>Good for me - Tuesday at 1600UTC
>>>
>>>
>>>-Original Message-
>>>From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
>>>Sent: Thursday, May 28, 2015 10:37 PM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
>>>backend support
>>>
>>>
>>>
>>>On May 28, 2015, at 12:47 PM, Hayes, Graham >>> wrote:
>>>
>>>On 28/05/15 19:38, Adam Harwell wrote:
>>>
>>>I haven't seen any responses from my team yet, but I know we'd be
>>>interested as well - we have done quite a bit of work on this in
>>>the past, including dealing with the Designate team on this very
>>>subject.
>>>We can be available most hours between 9am-6pm Monday-Friday CST.
>>>
>>>--Adam
>>>
>>>https://keybase.io/rm_you
>>>
>>>
>>>From: Rakesh Saha >>>>>>
>>>Reply-To: "OpenStack Development Mailing List (not for usage
>>> questions)"
>>>>>>>
>>> >>
>>>Date: Thursday, May 28, 2015 at 12:22 PM
>>>To: "OpenStack Development Mailing List (not for usage questions)"
>>>>>

[openstack-dev] [nova] Nova API improvement plan

[Sean Dague]

On the plane home from the Nova midcycle meetup I spent a chunk of time
reading our API docs that are now in tree:
https://github.com/openstack/nova/blob/master/doc/source/v2/2.0_server_concepts.rst
and it got me concerned that documentation improvements don't seem to be
the top priority on the API infrastructure side.

The API concept guide is a really useful (though currently horribly out
of date) document for someone trying to use the Nova API without reading
all the Nova code. I feel like without that kind of big picture view,
the Nova API is quite hard to sort out.

I'd like to get updating that much higher up the priority list for the
API subteam. I realize there is this large json home patch series out
there to add new hotness to the API, but I feel like json home is
premature until we've got a concept picture of the Nova API in
documentation.

How do we get this ball rolling? Who's up for helping? How do we get the
concept guide back onto developer.openstack.org once it's not horribly
out of date?

I don't feel like I've got a plan yet in my head, but I'd really like to
get one developed over the next couple of weeks so that we can actually
make some real progress here. So who is up for helping, and what format
this plan will take, are the key bits.

-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] [GSLB][GLB] Meeting today @ 16:00 UTC

[Hayes, Graham]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Reminder that we have a meeting today at 16:00 UTC in
#openstack-meeting-4


The Agenda is as follows:

API Spec:
* https://github.com/gslb/gslb-specs/pull/1
* Can cores review + merge?

Polaris Abstract:
* https://github.com/polaris-gslb/polaris-description
* Is this of interest to the community?
* If so, can everyone read the abstract, and come
  with feedback to the meeting?

Project Name:
* https://etherpad.openstack.org/p/GSLB_project_name_vote
* Time to decide!

AOB (Any Other Business)

In particular, can everyone have a quick ready of the Polaris
abstract? They are considering Open Sourcing it, and are looking for
feedback if we (the GLSB community) are interested in it.

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

iQEcBAEBAgAGBQJVwLUOAAoJEPRBUqpJBgIir2oIAI5DhbyZJnFtPjrTZVvbx7cJ
O0JRszkIR+7xUUUaUkBjKQHhAbtrccaKzfe4ZdzMyTqLGQJZB4rrky8evRx+e5IG
ASS/zCRY8RAIudwDHmGyE/hlq9abSvnlmL/MIlsgp/CQawUsYM2Fiuf5KmhcDtEs
Q98ATa5oyJrUHc+c2nRXLCBQI6J4ZcEJyXfLQ6nbXS7KvUzs+OM8v09vRiIIboXr
lX345vBZM68Emzz+bX6bTv/hN8/oxdN2GXzuQIG0d+9CLgpD70xp6YR7uPrLUkVf
o+mEUgDwA0prdg912xbDFbHzAoDyzCBFZO8F9ycn0C9aiwkZM8OX2rt6PTA3ZAg=
=m1n7
-END PGP SIGNATURE-


0x7D28E972.asc
Description: 0x7D28E972.asc
__
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] [python-neutronclient][neutron] sub-project client extensions

[Amir Sadoughi]

I started down the path of making a python-neutronclient extension, but got 
stuck on the lack of support for child resource extensions as described here 
https://bugs.launchpad.net/python-neutronclient/+bug/1446428. I submitted a 
bugfix here https://review.openstack.org/#/c/202597/?.


Amir



From: Fawad Khaliq 
Sent: Tuesday, August 4, 2015 6:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [python-neutronclient][neutron] sub-project client 
extensions

Folks,

In networking-plumgrid project, we intend to implement client side for some of 
the vendor specific extensions. Looking at the current implementation for 
client side for some vendors, I see the code is part of python-neutronclient 
tree [1]. I do see this change [2] talking about a way to load extensions 
through entry points, however, I could not find any example extension module.

Has anyone gone through the route of implementing out of tree extensions for 
Neutron client, which extend python-neutronclient shell and load at run/install 
time? With decomposition phase II, it makes sense to keep the client side in 
the respective projects as well.

[1] 
https://github.com/openstack/python-neutronclient/tree/master/neutronclient/neutron/v2_0
[2] https://review.openstack.org/#/c/148318/16

Thanks,
Fawad Khaliq

__
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] [nova][ironic] Scheduler filtering based on instances

[Jim Rollenhagen]

On Tue, Aug 04, 2015 at 09:52:40AM +0100, Lucas Alvares Gomes wrote:
> Hi,
> 
> > Our initial solution [1] was to simply disable instance queries in the
> > IronicHostManager, as they were never needed, and were painful to
> > execute. But subsequent discussion on IRC brought up some potential
> > (although not very likely) use cases where this might not be true. One
> > example was if there were two computes each talking to one of two
> > ironic installations, one might use the SameHostFilter to ensure that
> > a new ironic instance was placed in the same ironic environment as
> > another instance. While this seemed possible, the idea of querying
> > hundreds or thousands of instances to see if the target was in that
> > group seemed like overkill. I suggested that if this were ever
> > something that someone needed, creating a new filter would be a better
> > way forward than trying to retrofit the virt design onto ironic.
> >
> 
> Right, so my first suggestion would be to add a configuration option
> where one could toggle to enable or disable the new scheduler filters
> (defaulting to disabled). But if Nova doesn't want to add a new
> configuration option unless it's absolutely necessary I think we could
> just disable it for now (just like the patch is proposing right now)
> and open a bug about it so we can keep track of the problem. And if we
> figure out that this problem is affecting someone out there we can
> then fix it by whether adding the configuration option or creating a
> new filter or ... We can talk about the proper fix as part of that
> bug.

I'm also fine with this for now. The multiple-host work might help here,
too.

// jim

> 
> Cheers,
> Lucas
> 
> __
> 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] [Keystone][Fernet] HA SQL backend for Fernet keys

[Lance Bragstad]

On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov  wrote:

> On Monday 03 August 2015 21:05:00 David Stanek wrote:
>
> > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov 
> wrote:
>
> > > On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum  wrote:
>
> > > > This too is overly complex and will cause failures. If you replace
> key
>
> > > > 0,
>
> > > >
>
> > > > you will stop validating tokens that were encrypted with the old key
> 0.
>
> > >
>
> > > No. Key 0 is replaced after rotation.
>
> > >
>
> > >
>
> > >
>
> > > Also, come on, does http://paste.openstack.org/show/406674/ look
> overly
>
> > > complex? (it should be launched from Fuel master node).
>
> >
>
> > I'm reading this on a small phone, so I may have it wrong, but the script
>
> > appears to be broken.
>
> >
>
> > It will ssh to node-1 and rotate. In the simplest case this takes key 0
> and
>
> > moves it to the next highest key number. Then a new key 0 is generated.
>
> >
>
> > Later there is a loop that will again ssh into node-1 and run the
> rotation
>
> > script. If there is a limit set on the number of keys and you are at that
>
> > limit a key will be deleted. This extra rotation on node-1 means that
> it's
>
> > possible that it has a different set of keys than are on node-2 and
> node-3.
>
>
>
> You are absolutely right. Node-1 should be excluded from the loop.
>
>
>
> pinc also lacks "-c 1".
>
>
>
> I am sure that other issues can be found.
>
>
>
> In my excuse I want to say that I never ran the script and wrote it just
> to show how simple it should be. Thank for review though!
>
>
>
> I also hope that no one is going to use a script from a mailing list.
>
>
>
> > What's the issue with just a simple rsync of the directory?
>
>
>
> None I think. I just want to reuse the interface provided by
> keystone-manage.
>

You wanted to use the interface from keystone-manage to handle the actual
promotion of the staged key, right? This is why there were two
fernet_rotate commands issued?


>
>
> --
>
> С наилучшими пожеланиями,
>
> Boris
>
> __
> 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] [Fuel] SSL for master node API

[Vitaly Kramskikh]

FYI: There is Strict-Transport-Security
 header which
can also be useful here (unless we want to make SSL for master node
optional)

2015-08-04 15:07 GMT+03:00 Vladimir Sharshov :

> Hi,
>
> +1 to 2nd solution too.
>
> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> +1 to 2nd solution, in this case old environments will work without
>> additional
>> actions. Agents for new environments, CLI and UI will use SSL.
>> But probably for UI we will have to perform redirect on JS level.
>>
>> Thanks,
>>
>> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Hi guys,
>>> in overall movement of Fuel to use secure sockets we think about
>>> wrapping master node UI and API calls to SSL. But there are next caveat:
>>>
>>> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
>>> little. But if it will be rewritten in 7.0 and HTTPS on master node will be
>>> forced by default, it will break upgrade from previous releases to 7.0 due
>>> fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
>>> default and fuel-nailgun-agent on all environments won't upgraded, so it
>>> won't be able to connect to master node after upgrade. It breaks seamless
>>> upgrade procedure.
>>>
>>> What options I see there:
>>> 1. We can forcedly enable SSL for master node and rewrite clients in 7.0
>>> to be able to work over it. In release notes for 7.0 we will write
>>> forewarning that clients which want to upgrade master node from previous
>>> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
>>> all deployed environments.
>>>
>>> 2. We can have both SSL and non-SSL versions enabled by default and
>>> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
>>> availability and be able to work in plain HTTP for legacy mode. So, for all
>>> new environments SSL will be used by default and for old ones plain HTTP
>>> will continue to work too. Master node upgrade will not be broken in this
>>> case.
>>>
>>> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
>>> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
>>> releases. It is just postponed version of first clause, so it doesn't seems
>>> valid for me, actually.
>>>
>>> I would be really glad to hear what you think about this. Thank you in
>>> advance.
>>>
>>>
>>> __
>>> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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

[openstack-dev] [Fuel] Console messages in Mirantis 6.1

[Evgeniya Shumakher]

Fuel team,

One of Fuel 6.1 users found a very annoying bug:

I’ve installed new Mirantis 6.1 a couple of weeks ago and I’m seeing the
> following message on both Controller and Compute node consoles.
>
> “netlink: 20 bytes leftover after parsing attributes”
>
> There are several references to this bug:
> -  https://bugs.launchpad.net/fuel/+bug/1447543
> -  https://bugs.launchpad.net/fuel/+bug/1449914
>
> This messages don’t show in the SSH consoles, so I was able to configure
> all nodes for SSH access and sort of bypass this issue.
>
> So, it’s not critical to resolve it, but I have not seen any officially
> posted resolutions… Would you happen to know the status of this resolution?
>
> Thanks in advance!


Do I understand that the bug is medium and might not be fixed?
What would be the recommended response to this user?
Can we add information about this feature to Fuel documentation?


Thank you.

--
Evgeniya











-- 
Regards,
Evgeniya Shumakher
Partner Integrations Manager
Mirantis, Inc

Mob.phone: +7 (968) 760-98-42
Email: eshumak...@mirantis.com
Skype: eshumakher
__
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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2015-08-03 11:54:06 -0700:
> On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
> > Hi everyone,
> > 
> > A month ago the stable branch team decided to move away from
> > synchronized stable point releases and enable continuous stable branch
> > delivery instead.
> > 
> > The end goal is that every commit on a stable branch for a "service"
> > project will get a .Z version increment, and a tag be pushed to match.
> > So we'll have for example Nova 12.0.0 at Liberty release, and each
> > stable branch commit will result in 12.0.1, 12.0.2... versions.
> > 
> > In order to make this work, it looks like we'd require:
> > 
> > * pbr changes so that it supports a mode where every commit on the
> > branch increments .Z
> > 
> > * infra changes to automatically push the corresponding tag when the
> > commit is merged
> > 
> > To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80
> > (kilo) and Nova 10.0.218 (juno).
> I am not a fan of doing this second option at all. We would be polluting
> the ref space of our repos with redundant information making the output
> of `git tag` unusable to humans. If this was not redundant info and a
> tag of 11.0.80 provided more information than a generated version of
> 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.

One problem with dev versions that has been pointed out elsewhere
(by ttx?) is that it is difficult/impossible to distinguish between
11.0.0.dev80 on stable/kilo and a my-companys-patched/kilo branch,
since we're counting commits but the version doesn't actually depend
on the contents of those commits. Using explicit tags in our repo
endows those versions with a bit more "officialness".

I'm not sure why you see having more tags "polluting" the ref space, can
you elaborate on that?

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] [Fuel] SSL for master node API

[Sebastian Kalinowski]

+1 for option 2)

But I have a question: how do we fit with this into the scope of Feature
Freeze and Soft Code Freeze this week?
Any ETAs?

2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh :

> FYI: There is Strict-Transport-Security
>  header
> which can also be useful here (unless we want to make SSL for master node
> optional)
>
> 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov :
>
>> Hi,
>>
>> +1 to 2nd solution too.
>>
>> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:
>>
>>> Hi,
>>>
>>> +1 to 2nd solution, in this case old environments will work without
>>> additional
>>> actions. Agents for new environments, CLI and UI will use SSL.
>>> But probably for UI we will have to perform redirect on JS level.
>>>
>>> Thanks,
>>>
>>> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
 Hi guys,
 in overall movement of Fuel to use secure sockets we think about
 wrapping master node UI and API calls to SSL. But there are next caveat:

 a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten
 a little. But if it will be rewritten in 7.0 and HTTPS on master node will
 be forced by default, it will break upgrade from previous releases to 7.0
 due fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS
 by default and fuel-nailgun-agent on all environments won't upgraded, so it
 won't be able to connect to master node after upgrade. It breaks seamless
 upgrade procedure.

 What options I see there:
 1. We can forcedly enable SSL for master node and rewrite clients in
 7.0 to be able to work over it. In release notes for 7.0 we will write
 forewarning that clients which want to upgrade master node from previous
 releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
 all deployed environments.

 2. We can have both SSL and non-SSL versions enabled by default and
 rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
 availability and be able to work in plain HTTP for legacy mode. So, for all
 new environments SSL will be used by default and for old ones plain HTTP
 will continue to work too. Master node upgrade will not be broken in this
 case.

 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
 save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
 releases. It is just postponed version of first clause, so it doesn't seems
 valid for me, actually.

 I would be really glad to hear what you think about this. Thank you in
 advance.


 __
 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> 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
>
>
__
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] A possible solution for HA Active-Active

[Gorka Eguileor]

On Tue, Aug 04, 2015 at 09:28:58AM +, Fox, Kevin M wrote:
> Its been explained for Cinder, but not for other OpenStack projects that also 
> have needs in this area.
> 

For that, Flavio started a new thread "Does OpenStack need a common
solution for DLM?"

We are discussing Cinder specifics on this thread.

Cheers,
Gorka.

> Thanks,
> Kevin
> 
> 
> From: Gorka Eguileor
> Sent: Tuesday, August 04, 2015 1:39:07 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] A possible solution for HA Active-Active
> 
> On Mon, Aug 03, 2015 at 06:12:23PM +, Fox, Kevin M wrote:
> > For example, to parallel the conversation with databases:
> >
> > "We want a database". Well, that means mongodb, postgres, mysql, 
> > berkeleydb, etc
> >
> > "Oh, well, I need it to be a relational db", Well, that means postgresq, 
> > mysql, etc
> >
> > "Oh, and I need recursive queries"... that excludes even more.
> >
> > We are pretty sure "We want a distributed lock manager". What problems are 
> > we trying to solve using it, and what features do they require in the 
> > DLM/DLM Abstraction of choice? That will exclude some of them. It also may 
> > exclude abstraction layers that don't expose the features needed. 
> > (Recursive queries for example)
> >
> > Thanks,
> > Kevin
> > 
> 
> Kevin all that has already been explained:
> 
> http://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/
> http://gorka.eguileor.com/simpler-road-to-cinder-active-active/
> 
> As well as on IRC and this thread, I don't see the point of repeating it
> over and over again, at some point people need to start doing their
> homework and read what's already been said to get up to speed on the
> topic so we can move on.
> 
> Gorka.
> 
> > From: Gorka Eguileor [gegui...@redhat.com]
> > Sent: Monday, August 03, 2015 10:48 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Cinder] A possible solution for   HA  
> > Active-Active
> >
> > On Mon, Aug 03, 2015 at 03:42:48PM +, Fox, Kevin M wrote:
> > > I'm usually for abstraction layers, but they don't always pay off very 
> > > well due to catering to the lowest common denominator.
> > >
> > > Lets clearly define the problem space first. IFF the problem space can be 
> > > fully implemented using Tooz, then lets do that. Then the operator can 
> > > choose. If Tooz cant and wont handle the problem space, then we're trying 
> > > to fit a square peg in a round hole.
> >
> > What do you mean with clearly define the problem space?  We know what we
> > want, we just need to agree on the compromises we are willing to make,
> > use a DLM and make admins' life a little harder (only for those that
> > deploy A-A) but have an A-A solution earlier, or postpone A-A
> > functionality but make their life easier.
> >
> > And we already know that Tooz is not the Holy Grail and will not perform
> > the miracle of giving Cinder HA A-A.  It is only a piece of the problem,
> > so there's nothing to discuss there, and it's not a square peg on a
> > round hole, because it fits perfectly for what it is intended. But once
> > you have filled that square hole you need another peg, the round one for
> > the round hole.
> >
> > If people are expecting to find one thing that fixes everything and
> > gives us HA A-A on its own, then I believe they are a little bit lost.
> >
> > Gorka.
> >
> > >
> > > Thanks,
> > > Kevin
> > > 
> > > From: Gorka Eguileor [gegui...@redhat.com]
> > > Sent: Monday, August 03, 2015 1:43 AM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
> > > Active-Active
> > >
> > > On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> > > > Flavio Percoco wrote:
> > > > > [...]
> > > > > So, to summarize, I love the effort behind this. But, as others have
> > > > > mentioned, I'd like us to take a step back, run this accross teams and
> > > > > come up with an opinonated solution that would work for everyone.
> > > > >
> > > > > Starting this discussion now would allow us to prepare enough material
> > > > > to reach an agreement in Tokyo and work on a single solution for
> > > > > Mikata. This sounds like a good topic for a cross-project session.
> > > >
> > > > +1
> > > >
> > > > The last thing we want is to rush a solution that would only solve a
> > > > particular project use case. Personally I'd like us to pick the simplest
> > > > solution that can solve most of the use cases. Each of the solutions
> > > > bring something to the table -- Zookeeper is mature, Consul is
> > > > featureful, etcd is lean and simple... Let's not dive into the best
> > > > solution but clearly define the problem space first.
> > > >
> > > > --
> > > > Thierry Carrez (ttx)
> > > >
> > >
>

Re: [openstack-dev] [all] Does OpenStack need a common solution for DLM? (was: Re: [Cinder] A possible solution for HA Active-Active)

[Mark Voelker]

On Aug 3, 2015, at 6:09 PM, Flavio Percoco  wrote:
> 
> On 03/08/15 19:48 +0200, Gorka Eguileor wrote:
>> On Mon, Aug 03, 2015 at 03:42:48PM +, Fox, Kevin M wrote:
>>> I'm usually for abstraction layers, but they don't always pay off very well 
>>> due to catering to the lowest common denominator.
>>> 
>>> Lets clearly define the problem space first. IFF the problem space can be 
>>> fully implemented using Tooz, then lets do that. Then the operator can 
>>> choose. If Tooz cant and wont handle the problem space, then we're trying 
>>> to fit a square peg in a round hole.
>> 
>> What do you mean with clearly define the problem space?  We know what we
>> want, we just need to agree on the compromises we are willing to make,
>> use a DLM and make admins' life a little harder (only for those that
>> deploy A-A) but have an A-A solution earlier, or postpone A-A
>> functionality but make their life easier.
>> 
>> And we already know that Tooz is not the Holy Grail and will not perform
>> the miracle of giving Cinder HA A-A.  It is only a piece of the problem,
>> so there's nothing to discuss there, and it's not a square peg on a
>> round hole, because it fits perfectly for what it is intended. But once
>> you have filled that square hole you need another peg, the round one for
>> the round hole.
>> 
>> If people are expecting to find one thing that fixes everything and
>> gives us HA A-A on its own, then I believe they are a little bit lost.
> 
> As confusing as it seems, we've now moved from talking about just
> Cinder to understanding whether this is a problem many projects have
> and whether we can find a solution that will work for most of them.
> Therefore, I've renamed this thread to make this more evident.
> 
> Now, so far we have:
> 
> - Ironic has an internal distributed lock and it uses a hash-ring
> - Ceilometer uses tooz
> - Several projects use a file lock of some other fashion of
> distributed lock.
> - *Add yours here*



/me adds a couple more here and fixes formatting

From an operator’s point of view, it may be worth noting some other parts of 
various projects that could or do use the same systems that provide DLM 
capabilities in that *if* those systems solve well for multiple use cases, it 
may make operator’s lives easier to congeal around them when possible.  E.g.: 
fewer moving parts, less to debug, more shared logic.  From that perspective, 
Neutron has also had some discussion around tooz in the recent past as well for 
agent monitoring and state awareness.  This thread captures some of people’s 
thinking:

http://lists.openstack.org/pipermail/openstack-dev/2015-April/061268.html

And there’s a related spec for agent monitoring using tooz as an alternative to 
heartbeat/DB mechanisms currently in review here:

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

It may also be worth noting that some of the original thinking behind this came 
from Nova’s adoption of Zookeeper for ServiceGroups several years ago:

https://blueprints.launchpad.net/nova/+spec/zk-service-heartbeat

However when the Neutron community began discussing this, the idea of using 
tooz (which didn’t exist back when Nova implemented the ServiceGroup API’s) 
rather than using Zookeeper directly came up in review and seemed to make a lot 
more sense to everyone.  

And as I’ve noted, there are individual plugins that have already adopted tooz 
specifically for distributed locking, such as the NSXv plugin for Neutron:

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

At Your Service,

Mark T. Voelker



> 
> Each one of these projects has a specific use-case that doesn't
> necessarily overlap. I'd like to see those cases listed somewhere.
> We've done this in the past already and I believe we can do it now as
> well. As I've mentioned in another thread, Gorka has done this for
> Cinder already now we need to do it for other services too. Even if
> your project has a DLM in place, it'd be good to know what problem you
> solved with it as it may be a problem that other projects have as
> well.
> 
> As a community, we've been able to do away with adding a new service
> for DLM's thus far. I'm not saying we don't need one but, as mentioned
> in other threads, lets give this some more thought before we add a new
> service that'll make deploying and maintaining OpenStack harder.
> 
> Flavio
> 
>>> From: Gorka Eguileor [gegui...@redhat.com]
>>> Sent: Monday, August 03, 2015 1:43 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
>>> Active-Active
>>> 
>>> On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
>>> > Flavio Percoco wrote:
>>> > > [...]
>>> > > So, to summarize, I love the effort behind this. But, as others have
>>> > > mentioned, I'd like us to take a step back, run this accross teams and
>>> > > come up with an opinonated solution that would work for everyone.
>>> > >
>>> > > Starting this discussion now would allow u

Re: [openstack-dev] [nova] Thoughts on things that don't make freeze cutoffs

[Sahid Orentino Ferdjaoui]

On Tue, Aug 04, 2015 at 12:54:34PM +0200, Thierry Carrez wrote:
> John Garbutt wrote:
> > [...]
> > Personally I find a mix of coding and reviewing good to keep a decent
> > level of empathy and sanity. I don't have time for any coding this
> > release (only a bit of documenting), and its not something I can
> > honestly recommend as a best practice. If people don't maintain a good
> > level of reviews, we do tend to drop those folks from nova-core.
> > 
> > I know ttx has been pushing for dedicated reviewers. It would be nice
> > to find folks that can do that, but we just haven't found any of those
> > people to date.
> 
> Hell no! I'd hate dedicated reviewers.
>
> [...]
> This is why I advocate dividing code / reviewers / expertise along
> smaller areas within Nova, so that new people can focus and become a
> master again. What I'm pushing for is creating Nova subteams with their
> own core reviewers, which would be experts and trusted to +2 on a
> defined subset of code.

Yep this makes a lot of sense and unfortunately we bring this idea
every time but nothing seems to move in that way.

Contributors working in Nova feel more and more frustrated.

So specs got approved June 23-25 then about 15 working days to push
all of the code and 12 working days to make it merged. From my
experience working on Nova it's not possible. For instance on libvirt
driver we have one core who does most of the reviews, but we have
problem to find the +2/+W and without to mention problem when he
is author of the fix [1].

We delay good features (with code pushed and waiting reviews) we can
bring to users. I guess users are happy to hear that we are working
hard to improve our code base but perhaps they also want features
without to wait a year (3.1, 95, 98, me, xp...).

And I know that because I'm working every days in Nova since more than
2 years - We have really skilled people who can help.

[1] https://review.openstack.org/#/c/176360/

s.

__
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] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Ryan Moats]

I will be there for my lightning talk, and I think armax and kevin_benton
will be there - it would be good to find some time for us to pow-wow, along
with some teleconference so that carl_baldwin and mestery can join in...

Ryan Moats (regXboi)

Mike Dorman  wrote on 08/03/2015 10:07:23 PM:

> From: Mike Dorman 
> To: "OpenStack Development Mailing List (not for usage questions)"
> , OpenStack Operators  operat...@lists.openstack.org>
> Date: 08/03/2015 10:08 PM
> Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3]
> [Large Deployments Team] Representing a networks connected by routers
>
> I hope we can move this idea moving forward.  I was disappointed to see
> the spec abandoned.
>
> Some of us from the large deployers group will be at the Ops Meetup.
Will
> there be any representation from Neutron there that we could discuss with

> more?
>
> Thanks,
> Mike
>
>
>
>
>
> On 8/3/15, 12:27 PM, "Carl Baldwin"  wrote:
>
> >Kevin, sorry for the delay in response.  Keeping up on this thread was
> >getting difficult while on vacation.
> >
> >tl;dr:  I think it is worth it to talk through the idea of inserting
> >some sort of a "subnet group thing" in the model to which floating ips
> >(and router external gateways) will associate.  It has been on my mind
> >for a long time now.  I didn't pursue it because a few informal
> >attempts to discuss it with others indicated to me that it would be a
> >difficult heavy-lifting job that others may not appreciate or
> >understand.  Scroll to the bottom of this message for a little more on
> >this.
> >
> >Carl
> >
> >On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton  wrote:
> >>>Also, in my proposal, it is more the router that is the grouping
> >>>mechanism.
> >>
> >> I can't reconcile this with all of the points you make in the rest of
> >>your
> >> email. You want the collection of subnets that a network represents,
> >>but you
> >> don't want any other properties of the network.
> >
> >This is closer to what I'm trying to say but isn't quite there.  There
> >are some subnets that should be associated with the segments
> >themselves and there are some that should be associated with the
> >collection of segments.  I want floating IPs that are not tied the an
> >L2 network.  None of the alternate proposals that I'd heard addressed
> >this.
> >
> >>>that the network object is currently the closest thing we have to
> >>> representing the L3 part of the network.
> >>
> >> The L3 part of a network is the subnets. You can't have IP addresses
> >>without
> >> the subnets, you can't have floating IPs without the subnets, etc.
> >
> >You're right but in the current model you can't have IP addresses
> >without the network either which is actually the point I'm trying to
> >make.
> >
> >> A Neutron network is an L2 construct that encapsulates L3 things. By
> >> encapsulating them it also provides an implicit grouping. The routed
> >> networks proposal basically wants that implicit grouping without the
> >> encapsulation or the L2 part.
> >
> >This sounds about right.  I think it is wrong to assume that we need
> >an L2 network to encapsulate L3 things.  I'm feeling restricted by the
> >model and the insistence that a neutron network is a purely L2
> >construct.
> >
> >>>We don't associate floating ips with a network because we want to arp
> >>>for
> >>> them.  You're taking a consequence of the current model and its
> >>>constraints
> >>> and presenting that as the motivation for the model. We do so because

> >>>there
> >>> is no better L3 object to associate it to.
> >>
> >> Don't make assumptions about how people use floating IPs now just
> >>because it
> >> doesn't fit your use-case well. When an external network is
implemented
> >>as a
> >> real Neutron network (leaving external_network_bridge blank like we
> >>suggest
> >> in the networking guide), normal ports can be attached and can
> >> co-exist/communicate with the floating IPs because it behaves as an L2
> >> network exactly as implied by the API. The current model works quite
> >>well if
> >> your fabric can extend the external network everywhere it needs to be.
> >
> >Yes, "when an external network is implemented as a real Neutron
> >network" all of this is true and my proposal doesn't change any of
> >this.  I'm wasn't making any such assumptions.  I acknowledge that the
> >current model works well in this case and didn't intend to change it
> >for current use cases.  It is precisely that because it does not fit
> >my use case well that I'm pursuing this.
> >
> >Notice that a network marked only as external doesn't allow normal
> >tenants to create ports.  It must also be marked shared to allow it.
> >Unless tenants are creating regular ports then they really don't care
> >if arp or anything else L2 is involved because such an external
> >network is meant to give access external to the cloud where L2 is
> >really just an implementation detail.  It is the deployer that cares
> >because of whatever infrastructure

[openstack-dev] [Fuel] Console messages in Mirantis 6.1

[Evgeniya Shumakher]

> Fuel team,
>
> One of Fuel 6.1 users found a very annoying bug:
>
> I’ve installed new Mirantis 6.1 a couple of weeks ago and I’m seeing the
>> following message on both Controller and Compute node consoles.
>>
>> “netlink: 20 bytes leftover after parsing attributes”
>>
>> There are several references to this bug:
>> -  https://bugs.launchpad.net/fuel/+bug/1447543
>> -  https://bugs.launchpad.net/fuel/+bug/1449914
>>
>> This messages don’t show in the SSH consoles, so I was able to configure
>> all nodes for SSH access and sort of bypass this issue.
>>
>> So, it’s not critical to resolve it, but I have not seen any officially
>> posted resolutions… Would you happen to know the status of this resolution?
>>
>> Thanks in advance!
>
>
> Do I understand that the bug is medium and might not be fixed?
> What would be the recommended response to this user?
> Can we add information about this feature to Fuel documentation?
>
>
> Thank you.
>
> --
> Evgeniya
>
>
>
__
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] [Ceilometer][AODH] Timeout Event Alarms

[Igor Degtiarov]

Hi folks,

On our meatup we agreed to add timeout event alarms [1](Event-Base Alarming
part).
In ToDo task "Сhoose the optimal way for timeout alerting implementation"
Now we have two proposition for implementation:
 - first is to add timeout param in event pipeline (transformer part)
[2]
   -- weakness of this approach is that we cannot allow user change config
files, so only administrator will be able to set rules for timeout events
alarms, and that is not what we are expecting from alarms.
 - second is additional optional parameters in event alarms description
like sequence of required events and timeout threshold. Event alarm
evaluator looks thru getting events and evaluates alarm if even one event
from required sequence isn't received in set "timeout".[3]

It seems that second approach is better it doesn't have restrictions for
end user.
Hope for your help in choosing optimal way for implementation.
(In specs review there is silence now)

[1]
https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle
[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.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] [Fuel] SSL for master node API

[Stanislaw Bogatkin]

Seems that second solution is okay.

Sebastian, I'll try to fix it before SCF.

On Tue, Aug 4, 2015 at 4:25 PM, Sebastian Kalinowski <
skalinow...@mirantis.com> wrote:

> +1 for option 2)
>
> But I have a question: how do we fit with this into the scope of Feature
> Freeze and Soft Code Freeze this week?
> Any ETAs?
>
> 2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh :
>
>> FYI: There is Strict-Transport-Security
>>  header
>> which can also be useful here (unless we want to make SSL for master node
>> optional)
>>
>> 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov :
>>
>>> Hi,
>>>
>>> +1 to 2nd solution too.
>>>
>>> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:
>>>
 Hi,

 +1 to 2nd solution, in this case old environments will work without
 additional
 actions. Agents for new environments, CLI and UI will use SSL.
 But probably for UI we will have to perform redirect on JS level.

 Thanks,

 On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin <
 sbogat...@mirantis.com> wrote:

> Hi guys,
> in overall movement of Fuel to use secure sockets we think about
> wrapping master node UI and API calls to SSL. But there are next caveat:
>
> a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten
> a little. But if it will be rewritten in 7.0 and HTTPS on master node will
> be forced by default, it will break upgrade from previous releases to 7.0
> due fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS
> by default and fuel-nailgun-agent on all environments won't upgraded, so 
> it
> won't be able to connect to master node after upgrade. It breaks seamless
> upgrade procedure.
>
> What options I see there:
> 1. We can forcedly enable SSL for master node and rewrite clients in
> 7.0 to be able to work over it. In release notes for 7.0 we will write
> forewarning that clients which want to upgrade master node from previous
> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
> all deployed environments.
>
> 2. We can have both SSL and non-SSL versions enabled by default and
> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
> availability and be able to work in plain HTTP for legacy mode. So, for 
> all
> new environments SSL will be used by default and for old ones plain HTTP
> will continue to work too. Master node upgrade will not be broken in this
> case.
>
> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in 
> next
> releases. It is just postponed version of first clause, so it doesn't 
> seems
> valid for me, actually.
>
> I would be really glad to hear what you think about this. Thank you in
> advance.
>
>
> __
> 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
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> 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
>>
>>
>
> __
> 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] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Kyle Mestery]

Can you also try to have some sort of remote option? I'd like to attend
this, and I'd like Carl to try and attend as well. Thanks!

On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats  wrote:

> I will be there for my lightning talk, and I think armax and kevin_benton
> will be there - it would be good to find some time for us to pow-wow, along
> with some teleconference so that carl_baldwin and mestery can join in...
>
> Ryan Moats (regXboi)
>
> Mike Dorman  wrote on 08/03/2015 10:07:23 PM:
>
> > From: Mike Dorman 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > , OpenStack Operators  > operat...@lists.openstack.org>
> > Date: 08/03/2015 10:08 PM
> > Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3]
> > [Large Deployments Team] Representing a networks connected by routers
>
> >
> > I hope we can move this idea moving forward.  I was disappointed to see
> > the spec abandoned.
> >
> > Some of us from the large deployers group will be at the Ops Meetup.
> Will
> > there be any representation from Neutron there that we could discuss
> with
> > more?
> >
> > Thanks,
> > Mike
> >
> >
> >
> >
> >
> > On 8/3/15, 12:27 PM, "Carl Baldwin"  wrote:
> >
> > >Kevin, sorry for the delay in response.  Keeping up on this thread was
> > >getting difficult while on vacation.
> > >
> > >tl;dr:  I think it is worth it to talk through the idea of inserting
> > >some sort of a "subnet group thing" in the model to which floating ips
> > >(and router external gateways) will associate.  It has been on my mind
> > >for a long time now.  I didn't pursue it because a few informal
> > >attempts to discuss it with others indicated to me that it would be a
> > >difficult heavy-lifting job that others may not appreciate or
> > >understand.  Scroll to the bottom of this message for a little more on
> > >this.
> > >
> > >Carl
> > >
> > >On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton 
> wrote:
> > >>>Also, in my proposal, it is more the router that is the grouping
> > >>>mechanism.
> > >>
> > >> I can't reconcile this with all of the points you make in the rest of
> > >>your
> > >> email. You want the collection of subnets that a network represents,
> > >>but you
> > >> don't want any other properties of the network.
> > >
> > >This is closer to what I'm trying to say but isn't quite there.  There
> > >are some subnets that should be associated with the segments
> > >themselves and there are some that should be associated with the
> > >collection of segments.  I want floating IPs that are not tied the an
> > >L2 network.  None of the alternate proposals that I'd heard addressed
> > >this.
> > >
> > >>>that the network object is currently the closest thing we have to
> > >>> representing the L3 part of the network.
> > >>
> > >> The L3 part of a network is the subnets. You can't have IP addresses
> > >>without
> > >> the subnets, you can't have floating IPs without the subnets, etc.
> > >
> > >You're right but in the current model you can't have IP addresses
> > >without the network either which is actually the point I'm trying to
> > >make.
> > >
> > >> A Neutron network is an L2 construct that encapsulates L3 things. By
> > >> encapsulating them it also provides an implicit grouping. The routed
> > >> networks proposal basically wants that implicit grouping without the
> > >> encapsulation or the L2 part.
> > >
> > >This sounds about right.  I think it is wrong to assume that we need
> > >an L2 network to encapsulate L3 things.  I'm feeling restricted by the
> > >model and the insistence that a neutron network is a purely L2
> > >construct.
> > >
> > >>>We don't associate floating ips with a network because we want to arp
> > >>>for
> > >>> them.  You're taking a consequence of the current model and its
> > >>>constraints
> > >>> and presenting that as the motivation for the model. We do so
> because
> > >>>there
> > >>> is no better L3 object to associate it to.
> > >>
> > >> Don't make assumptions about how people use floating IPs now just
> > >>because it
> > >> doesn't fit your use-case well. When an external network is
> implemented
> > >>as a
> > >> real Neutron network (leaving external_network_bridge blank like we
> > >>suggest
> > >> in the networking guide), normal ports can be attached and can
> > >> co-exist/communicate with the floating IPs because it behaves as an L2
> > >> network exactly as implied by the API. The current model works quite
> > >>well if
> > >> your fabric can extend the external network everywhere it needs to be.
> > >
> > >Yes, "when an external network is implemented as a real Neutron
> > >network" all of this is true and my proposal doesn't change any of
> > >this.  I'm wasn't making any such assumptions.  I acknowledge that the
> > >current model works well in this case and didn't intend to change it
> > >for current use cases.  It is precisely that because it does not fit
> > >my use case well that I'm pursuing this.
> > >
> > >Notice that a network marked only as exter

Re: [openstack-dev] [Fuel] Console messages in Mirantis 6.1

[Alex Schultz]

Hey Evgeniya,



On Tue, Aug 4, 2015 at 8:59 AM, Evgeniya Shumakher 
wrote:

>
> Fuel team,
>>
>> One of Fuel 6.1 users found a very annoying bug:
>>
>> I’ve installed new Mirantis 6.1 a couple of weeks ago and I’m seeing the
>>> following message on both Controller and Compute node consoles.
>>>
>>> “netlink: 20 bytes leftover after parsing attributes”
>>>
>>> There are several references to this bug:
>>> -  https://bugs.launchpad.net/fuel/+bug/1447543
>>> -  https://bugs.launchpad.net/fuel/+bug/1449914
>>>
>>> This messages don’t show in the SSH consoles, so I was able to configure
>>> all nodes for SSH access and sort of bypass this issue.
>>>
>>> So, it’s not critical to resolve it, but I have not seen any officially
>>> posted resolutions… Would you happen to know the status of this resolution?
>>>
>>> Thanks in advance!
>>
>>
>> Do I understand that the bug is medium and might not be fixed?
>> What would be the recommended response to this user?
>> Can we add information about this feature to Fuel documentation?
>>
>>
The bug for this issue is https://bugs.launchpad.net/fuel/+bug/180.  It
is unfortunately an upstream (centos 6) issue that I don't believe we will
be fixing.  The messages themselves are not an issue but they do take up
space in logs so if that is a problem, we would need to fix that via proper
log rotation.  Do we have reports of excessive logs due to netlink error
messages?


>
>> Thank you.
>>
>> --
>> Evgeniya
>>
>>
>>
> __
> 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
>
>
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

Re: [openstack-dev] [nova] Bug Triage Day - Liberty

[Markus Zoeller]

This is a short reminder that we intend to do a "bug triage day"
tomorrow, Wednesday 5th. Would be great if you could participate.

Regards,
Markus Zoeller (markus_z)

John Garbutt  wrote on 07/29/2015 07:21:31 PM:

> From: John Garbutt 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 07/29/2015 07:25 PM
> Subject: Re: [openstack-dev] [nova] Bug Triage Day - Liberty
> 
> On 29 July 2015 at 17:13, Jay Pipes  wrote:
> > On 07/29/2015 08:13 AM, Markus Zoeller wrote:
> >>
> >> I'd like to spread the idea of doing a "bug triage day" on next
> >> Wednesday, August 5th.
> >>
> >> This is one of our special review days [1] and sets the ground for 
the
> >> following timeframe where we focus on fixing bugs. Would be great if 
you
> >> could shift your focus on this day to triaging [2] to
> >> * review critical/high bugs (bug supervisors)
> >> * prioritize confirmed/triaged bugs (bug supervisors)
> >> * confirm/invalidate new bugs   (anyone)
> >> Most of the bugs are tagged to enable a filtering for contributors 
which
> >> have expertise in these certain areas [3]. Some tags don't yet have
> >> contributors associated, you're welcomed to join in.
> >> If you have questions, contact me (markus_z) or another member of the
> >> nova bug team on IRC #openstack-nova.
> >> [1] special review days:
> >>
> >> https://wiki.openstack.org/wiki/Nova/
> Liberty_Release_Schedule#Special_review_days
> >> [2] common bug triage: https://wiki.openstack.org/wiki/BugTriage
> >> [3] bug tag owner: https://wiki.openstack.org/wiki/Nova/BugTriage
> >> [4] Nova Bug Team: https://launchpad.net/~nova-bugs
> >
> >
> > ++ Thank you for taking this initiative, Markus!
> 
> +1
> 
> Please note the change in date from the previously announced date (it
> moved from the Friday to the Wednesday).
> 
> All hail our new Bug Czar [1]!
> 
> Thanks,
> John
> 
> [1] https://wiki.openstack.org/wiki/Nova#People
> 
> 
__
> 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] [Fuel] Console messages in Mirantis 6.1

[Sergii Golovatiuk]

Evgeniya,

These bug doesn't affect any functionality. These bugs are warnings only
that's why they were moved to 8.0. In 8.0 we are switching dynamically
built bootstrap based on Ubuntu 14.04 or Centos 7. These warnings will have
gone automatically.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Aug 4, 2015 at 3:08 PM, Evgeniya Shumakher 
wrote:

> Fuel team,
>
> One of Fuel 6.1 users found a very annoying bug:
>
> I’ve installed new Mirantis 6.1 a couple of weeks ago and I’m seeing the
>> following message on both Controller and Compute node consoles.
>>
>> “netlink: 20 bytes leftover after parsing attributes”
>>
>> There are several references to this bug:
>> -  https://bugs.launchpad.net/fuel/+bug/1447543
>> -  https://bugs.launchpad.net/fuel/+bug/1449914
>>
>> This messages don’t show in the SSH consoles, so I was able to configure
>> all nodes for SSH access and sort of bypass this issue.
>>
>> So, it’s not critical to resolve it, but I have not seen any officially
>> posted resolutions… Would you happen to know the status of this resolution?
>>
>> Thanks in advance!
>
>
> Do I understand that the bug is medium and might not be fixed?
> What would be the recommended response to this user?
> Can we add information about this feature to Fuel documentation?
>
>
> Thank you.
>
> --
> Evgeniya
>
>
>
>
>
>
>
>
>
>
>
> --
> Regards,
> Evgeniya Shumakher
> Partner Integrations Manager
> Mirantis, Inc
>
> Mob.phone: +7 (968) 760-98-42
> Email: eshumak...@mirantis.com
> Skype: eshumakher
>
> __
> 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] [Keystone][Fernet] HA SQL backend for Fernet keys

[Boris Bobrov]

On Tuesday 04 August 2015 08:06:21 Lance Bragstad wrote:
> On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov  wrote:
> > On Monday 03 August 2015 21:05:00 David Stanek wrote:
> > > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov 
> > 
> > wrote:
> > > > Also, come on, does http://paste.openstack.org/show/406674/ look
> > > > overly
> > > > complex? (it should be launched from Fuel master node).
> > > 
> > > I'm reading this on a small phone, so I may have it wrong, but the
> > > script
> > > 
> > > appears to be broken.
> > > 
> > > 
> > > 
> > > It will ssh to node-1 and rotate. In the simplest case this takes key
> > > 0
> > 
> > and
> > 
> > > moves it to the next highest key number. Then a new key 0 is
> > > generated.
> > > 
> > > 
> > > 
> > > Later there is a loop that will again ssh into node-1 and run the
> > 
> > rotation
> > 
> > > script. If there is a limit set on the number of keys and you are at
> > > that
> > > 
> > > limit a key will be deleted. This extra rotation on node-1 means that
> > 
> > it's
> > 
> > > possible that it has a different set of keys than are on node-2 and
> > 
> > node-3.
> > 
> > 
> > 
> > You are absolutely right. Node-1 should be excluded from the loop.
> > 
> > 
> > 
> > pinc also lacks "-c 1".
> > 
> > 
> > 
> > I am sure that other issues can be found.
> > 
> > 
> > 
> > In my excuse I want to say that I never ran the script and wrote it just
> > to show how simple it should be. Thank for review though!
> > 
> > 
> > 
> > I also hope that no one is going to use a script from a mailing list.
> > 
> > > What's the issue with just a simple rsync of the directory?
> > 
> > None I think. I just want to reuse the interface provided by
> > keystone-manage.
> 
> You wanted to use the interface from keystone-manage to handle the actual
> promotion of the staged key, right? This is why there were two
> fernet_rotate commands issued?

Right. Here is the fixed version (please don't use it anyway): 
http://paste.openstack.org/show/406862/

-- 
Best regards,
Boris Bobrov

__
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] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Mike Dorman]

Ok, cool.  We plan to discuss this during the LDT time slot at 1330-1500 
Pacific on Tuesday 8/18.  We can have this as the first agenda item so there’s 
a defined start time for those who are remote.

I'll take ownership of setting up a hangout (or whatever.)  Do people have a 
preference on what videoconference tool to us?  Absent any opinions, I’ll just 
do a Google Hangout.

Thanks!
Mike


From: Kyle Mestery
Date: Tuesday, August 4, 2015 at 8:09 AM
To: Ryan Moats
Cc: Mike Dorman, "OpenStack Development Mailing List (not for usage 
questions)", OpenStack Operators
Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large 
Deployments Team] Representing a networks connected by routers

Can you also try to have some sort of remote option? I'd like to attend this, 
and I'd like Carl to try and attend as well. Thanks!

On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats 
mailto:rmo...@us.ibm.com>> wrote:

I will be there for my lightning talk, and I think armax and kevin_benton will 
be there - it would be good to find some time for us to pow-wow, along with 
some teleconference so that carl_baldwin and mestery can join in...

Ryan Moats (regXboi)

Mike Dorman mailto:mdor...@godaddy.com>> wrote on 
08/03/2015 10:07:23 PM:

> From: Mike Dorman mailto:mdor...@godaddy.com>>
> To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-dev@lists.openstack.org>>,
>  OpenStack Operators  operat...@lists.openstack.org>
> Date: 08/03/2015 10:08 PM
> Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3]
> [Large Deployments Team] Representing a networks connected by routers

>
> I hope we can move this idea moving forward.  I was disappointed to see
> the spec abandoned.
>
> Some of us from the large deployers group will be at the Ops Meetup.  Will
> there be any representation from Neutron there that we could discuss with
> more?
>
> Thanks,
> Mike
>
>
>
>
>
> On 8/3/15, 12:27 PM, "Carl Baldwin" 
> mailto:c...@ecbaldwin.net>> wrote:
>
> >Kevin, sorry for the delay in response.  Keeping up on this thread was
> >getting difficult while on vacation.
> >
> >tl;dr:  I think it is worth it to talk through the idea of inserting
> >some sort of a "subnet group thing" in the model to which floating ips
> >(and router external gateways) will associate.  It has been on my mind
> >for a long time now.  I didn't pursue it because a few informal
> >attempts to discuss it with others indicated to me that it would be a
> >difficult heavy-lifting job that others may not appreciate or
> >understand.  Scroll to the bottom of this message for a little more on
> >this.
> >
> >Carl
> >
> >On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton 
> >mailto:blak...@gmail.com>> wrote:
> >>>Also, in my proposal, it is more the router that is the grouping
> >>>mechanism.
> >>
> >> I can't reconcile this with all of the points you make in the rest of
> >>your
> >> email. You want the collection of subnets that a network represents,
> >>but you
> >> don't want any other properties of the network.
> >
> >This is closer to what I'm trying to say but isn't quite there.  There
> >are some subnets that should be associated with the segments
> >themselves and there are some that should be associated with the
> >collection of segments.  I want floating IPs that are not tied the an
> >L2 network.  None of the alternate proposals that I'd heard addressed
> >this.
> >
> >>>that the network object is currently the closest thing we have to
> >>> representing the L3 part of the network.
> >>
> >> The L3 part of a network is the subnets. You can't have IP addresses
> >>without
> >> the subnets, you can't have floating IPs without the subnets, etc.
> >
> >You're right but in the current model you can't have IP addresses
> >without the network either which is actually the point I'm trying to
> >make.
> >
> >> A Neutron network is an L2 construct that encapsulates L3 things. By
> >> encapsulating them it also provides an implicit grouping. The routed
> >> networks proposal basically wants that implicit grouping without the
> >> encapsulation or the L2 part.
> >
> >This sounds about right.  I think it is wrong to assume that we need
> >an L2 network to encapsulate L3 things.  I'm feeling restricted by the
> >model and the insistence that a neutron network is a purely L2
> >construct.
> >
> >>>We don't associate floating ips with a network because we want to arp
> >>>for
> >>> them.  You're taking a consequence of the current model and its
> >>>constraints
> >>> and presenting that as the motivation for the model. We do so because
> >>>there
> >>> is no better L3 object to associate it to.
> >>
> >> Don't make assumptions about how people use floating IPs now just
> >>because it
> >> doesn't fit your use-case well. When an external network is implemented
> >>as a
> >> real Neutron network (leaving external_network_bridge blank like we
> >>suggest
> >> in the networking guide), normal ports can 

[openstack-dev] Hyper-V 2008 R2 support

[Alessandro Pilotti]

Hi guys,

Just a quick note on the Windows editions support matrix updates for the Nova
Hyper-V driver and Neutron networking-hyperv ML2 agent:  

We are planning to drop legacy Windows Server / Hyper-V Server 2008 R2 support
starting with Liberty.

Windows Server / Hyper-V Server 2012 and above will continue to be supported.

Thanks,

Alessandro


__
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][api] New API Guidelines read for cross project review

[michael mccune]

hey all,

we have 2 API Guidelines that are ready for final review.

1. No project uses f_ prefix in filter params
https://review.openstack.org/#/c/198547/

2. RFC 5789 doesn't specify certain uses of PUT
https://review.openstack.org/#/c/199597/

if the API Working Group hasn't received any further feedback, we'll
merge them on August 11.

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

Re: [openstack-dev] [Openstack-operators] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Kyle Mestery]

Google Hangout should work fine! And Carl and I will both be at Linuxcon
and together, so we can dial in together. This time should work for us, so
thanks for taking us into consideration Mike!

Kyle

On Tue, Aug 4, 2015 at 9:29 AM, Mike Dorman  wrote:

> Ok, cool.  We plan to discuss this during the LDT time slot at 1330-1500
> Pacific on Tuesday 8/18.  We can have this as the first agenda item so
> there’s a defined start time for those who are remote.
>
> I'll take ownership of setting up a hangout (or whatever.)  Do people have
> a preference on what videoconference tool to us?  Absent any opinions, I’ll
> just do a Google Hangout.
>
> Thanks!
> Mike
>
>
> From: Kyle Mestery
> Date: Tuesday, August 4, 2015 at 8:09 AM
> To: Ryan Moats
> Cc: Mike Dorman, "OpenStack Development Mailing List (not for usage
> questions)", OpenStack Operators
>
> Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large
> Deployments Team] Representing a networks connected by routers
>
> Can you also try to have some sort of remote option? I'd like to attend
> this, and I'd like Carl to try and attend as well. Thanks!
>
> On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats  wrote:
>
>> I will be there for my lightning talk, and I think armax and kevin_benton
>> will be there - it would be good to find some time for us to pow-wow, along
>> with some teleconference so that carl_baldwin and mestery can join in...
>>
>> Ryan Moats (regXboi)
>>
>> Mike Dorman  wrote on 08/03/2015 10:07:23 PM:
>>
>> > From: Mike Dorman 
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > , OpenStack Operators > > operat...@lists.openstack.org>
>> > Date: 08/03/2015 10:08 PM
>> > Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3]
>> > [Large Deployments Team] Representing a networks connected by routers
>>
>> >
>> > I hope we can move this idea moving forward.  I was disappointed to see
>> > the spec abandoned.
>> >
>> > Some of us from the large deployers group will be at the Ops Meetup.
>> Will
>> > there be any representation from Neutron there that we could discuss
>> with
>> > more?
>> >
>> > Thanks,
>> > Mike
>> >
>> >
>> >
>> >
>> >
>> > On 8/3/15, 12:27 PM, "Carl Baldwin"  wrote:
>> >
>> > >Kevin, sorry for the delay in response.  Keeping up on this thread was
>> > >getting difficult while on vacation.
>> > >
>> > >tl;dr:  I think it is worth it to talk through the idea of inserting
>> > >some sort of a "subnet group thing" in the model to which floating ips
>> > >(and router external gateways) will associate.  It has been on my mind
>> > >for a long time now.  I didn't pursue it because a few informal
>> > >attempts to discuss it with others indicated to me that it would be a
>> > >difficult heavy-lifting job that others may not appreciate or
>> > >understand.  Scroll to the bottom of this message for a little more on
>> > >this.
>> > >
>> > >Carl
>> > >
>> > >On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton 
>> wrote:
>> > >>>Also, in my proposal, it is more the router that is the grouping
>> > >>>mechanism.
>> > >>
>> > >> I can't reconcile this with all of the points you make in the rest
>> of
>> > >>your
>> > >> email. You want the collection of subnets that a network represents,
>> > >>but you
>> > >> don't want any other properties of the network.
>> > >
>> > >This is closer to what I'm trying to say but isn't quite there.  There
>> > >are some subnets that should be associated with the segments
>> > >themselves and there are some that should be associated with the
>> > >collection of segments.  I want floating IPs that are not tied the an
>> > >L2 network.  None of the alternate proposals that I'd heard addressed
>> > >this.
>> > >
>> > >>>that the network object is currently the closest thing we have to
>> > >>> representing the L3 part of the network.
>> > >>
>> > >> The L3 part of a network is the subnets. You can't have IP addresses
>> > >>without
>> > >> the subnets, you can't have floating IPs without the subnets, etc.
>> > >
>> > >You're right but in the current model you can't have IP addresses
>> > >without the network either which is actually the point I'm trying to
>> > >make.
>> > >
>> > >> A Neutron network is an L2 construct that encapsulates L3 things. By
>> > >> encapsulating them it also provides an implicit grouping. The routed
>> > >> networks proposal basically wants that implicit grouping without the
>> > >> encapsulation or the L2 part.
>> > >
>> > >This sounds about right.  I think it is wrong to assume that we need
>> > >an L2 network to encapsulate L3 things.  I'm feeling restricted by the
>> > >model and the insistence that a neutron network is a purely L2
>> > >construct.
>> > >
>> > >>>We don't associate floating ips with a network because we want to
>> arp
>> > >>>for
>> > >>> them.  You're taking a consequence of the current model and its
>> > >>>constraints
>> > >>> and presenting that as the motivation for the model. We do so
>> because
>> > >>>there
>> > >>> i

Re: [openstack-dev] [nova] Nova API improvement plan

[Anne Gentle]

On Tue, Aug 4, 2015 at 7:48 AM, Sean Dague  wrote:

> On the plane home from the Nova midcycle meetup I spent a chunk of time
> reading our API docs that are now in tree:
>
> https://github.com/openstack/nova/blob/master/doc/source/v2/2.0_server_concepts.rst
> and it got me concerned that documentation improvements don't seem to be
> the top priority on the API infrastructure side.
>
> The API concept guide is a really useful (though currently horribly out
> of date) document for someone trying to use the Nova API without reading
> all the Nova code. I feel like without that kind of big picture view,
> the Nova API is quite hard to sort out.
>
> I'd like to get updating that much higher up the priority list for the
> API subteam. I realize there is this large json home patch series out
> there to add new hotness to the API, but I feel like json home is
> premature until we've got a concept picture of the Nova API in
> documentation.
>
> How do we get this ball rolling? Who's up for helping? How do we get the
> concept guide back onto developer.openstack.org once it's not horribly
> out of date?
>
> I don't feel like I've got a plan yet in my head, but I'd really like to
> get one developed over the next couple of weeks so that we can actually
> make some real progress here. So who is up for helping, and what format
> this plan will take, are the key bits.
>


I'm up for helping, and it's related to our work on
http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html,
because ideally we'll build the API dev guides on developer.openstack.org.

Can you use the plan we've got now and help out? What would you adjust, the
"narrative" portion publishing?
Thanks,
Anne


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



-- 
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] [nova] Proposal for an Experiment

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/03/2015 02:24 PM, Jesse Cook wrote:

> Performance tests against 1000 node clusters being setup by OSIC? 
> Sounds like you have a playground for your tests.

Unfortunately, the consensus of the nova cores during the mid-cycle
meetup was that while this is an interesting approach, and that
experimenting with novel approaches can be very worthwhile, it was not
considered a priority, as there is too much work already on everyone's
plate for Liberty. So the experiment isn't going to happen any time soon
.

- -- 

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

iQIbBAEBCgAGBQJVwM5gAAoJEKMgtcocwZqLG90P9RNKm4pRmcLPK+PqVaXCIu/E
c+i0SW9Af5fmy4cC7Efnuv2o7UqJNNU7GsGw3on54Lt1SoF3z1yJ/9WarzjiNLq+
25Uz+2HDytovvnREi+P/LoVB4mj49nowEkMh/3QgQWVsMOvPitPM7mBPAGkyzNvb
5ElC1Xr2HkyQ/9h34IGLWcC/X/meR79BcvRHfJwqzNyTP2foi7tboq4sugbFVQfy
72vbaTAtLI/mDzUjkafNGB5W2ge4VWAJRsjf1y+eIv+j2f3PKbKsx3XLrTIuzJ78
9qBmpGal/biqyUwFyrvrg/e//KuD0FhJdiDwiuc35hebkN7UBJbq71RAjdxtK4Jr
clImy04sGAvKI0r27LFZA3ycjv0J8OW4nJeH9vjdBg5N2D0FuhOIBNxXsKohdF42
0maWFe1Wj7Icv9YnJ26ZaaWjqwnGE/PjVl3lFd1X5W7KFJ5Ay/uYY28cfHbD0wKT
Ych2oSR0/Jrzzfm9jd+VP2kjORgtEdDaARbP11auT+o1xnIKLIA9qTiOGuhX807L
cZVitPoUdIlogQyKJ6hZtiIytrnnYocHKZp/MQjpTabVKkl4aKmKLAo2onNgDcD8
6B08hmsW28pm7aKZf0SBb7oe6OU0vCQjFaKWAVb1O+zGqspOrhqehQR3u6nF+O1Y
TaG3j4n4w/5D9gadk4k=
=l9oR
-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] [fuel][fuel-library] Librarian changes

[Alex Schultz]

To follow up on the merge schedule as we've merged some items and the apt
mirror issue has been resolved.

Friday 7/31 (COMPLETE)
librarian - https://review.openstack.org/#/c/202763/
stdlib - https://review.openstack.org/#/c/203386/

Monday 8/3 (COMPLETE)
concat - https://review.openstack.org/#/c/203387/
inifile - https://review.openstack.org/#/c/203395/

Tuesday 8/4 (COMPLETE)
xinetd - https://review.openstack.org/#/c/203393/
ssh - https://review.openstack.org/#/c/203392/

Wednesday 8/5 (On target)
ntp - https://review.openstack.org/#/c/203390/

Thursday 8/6
apache - https://review.openstack.org/#/c/203388/
apt - https://review.openstack.org/#/c/203389/

Monday 8/10
firewall - https://review.openstack.org/#/c/203396/

I have reached out to those responsible for the cinder module and they are
OK with merging this provided QA signs off on a custom iso with this
change.  I plan on getting the iso together today and hopefully can get a
QA resource to test cinder out thoroughly.  If QA is ok, this should be
merged on Tuesday 8/11.
cinder - https://review.openstack.org/#/c/203394/


Thanks,
-Alex

On Fri, Jul 31, 2015 at 12:11 PM, Alex Schultz 
wrote:

> Here is the proposed schedule and adjusted ordering based on risk due to
> code changes. Please let me know if you would like any of these dates
> changed.  You will see that I have bumped modules that were upgrades to
> later so that we can stop prior to this changes if we feel they are too
> risky.  We should be safe due to zero puppet code changes up until the ssh
> module.
>
> Today 7/31
> librarian - https://review.openstack.org/#/c/202763/
> stdlib - https://review.openstack.org/#/c/203386/
>
> Monday 8/3
> concat - https://review.openstack.org/#/c/203387/
> inifile - https://review.openstack.org/#/c/203395/
>
> Tuesday 8/4
> xinetd - https://review.openstack.org/#/c/203393/
> ssh - https://review.openstack.org/#/c/203392/
>
> Wednesday 8/5
> ntp - https://review.openstack.org/#/c/203390/
>
> Thursday 8/6
> apache - https://review.openstack.org/#/c/203388/
>
> Monday 8/10
> firewall - https://review.openstack.org/#/c/203396/
>
> This commit should be signed off by the teams who will ultimately be
> responsible for it to ensure they are familiar with the workflows
> involved[0]. It has no code changes, but may impact bug fixing so we may
> want to wait until 8.0 for this. If not, it should be done last.
> cinder - https://review.openstack.org/#/c/203394/
>
> This cannot be merged until we get a fuel-infra mirror, but is a change
> with no code changes so can be done whenever the mirror gets resolved.
> apt - https://review.openstack.org/#/c/203389/
>
> If at any point there are issues and we decide to revert back, they
> commits just need to be reverted in reverse order and we can use the webui
> to do so.  I will finish re-ordering the patches today, but we should be OK
> through the ntp module at this time.
>
> Thanks,
> -Alex
>
> [0] https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules
>
> On Fri, Jul 31, 2015 at 11:39 AM, Vladimir Kuklin 
> wrote:
>
>> Okay, folks, we had a short meeting to synchronize our vision of how it
>> should happen.
>>
>> We will start by merging least-invasive modules like stdlib today and
>> then continue doing merges one by one in discrete manner and revert things
>> immediately if something goes wrong.
>>
>> So there is a list of action items:
>>
>> Alex Schultz will send a schedule of which modules will be merged on
>> which week and ensure that core reviewers know which commits they should
>> merge when either by keeping W-1 on particular commits or by sharing the
>> schedule in commit message so that noone can forget about it or maybe some
>> other conveinent method that he can invent.
>>
>> I will remove my -2 for the inital librarian commit.
>>
>>
>> Thanks everyone for the collaboration and not calling me a selfish
>> lunatic :-)
>>
>>
>> On Fri, Jul 31, 2015 at 6:29 PM, Mike Scherbakov <
>> mscherba...@mirantis.com> wrote:
>>
>>> Vladimir,
>>> can you please elaborate on "such invasive changes"?
>>>
>>> There was a plan developed, including risk mitigation, etc. - like do
>>> 'grep -r' to check, and revert the change all together right away if we see
>>> regression. So far, everyone was aligned with the plan. It was discussed
>>> yesterday during IRC meeting [1]. Again, no one had objections.
>>>
>>> Please provide your concerns, explain your opinion in more details. I'd
>>> like other core reviewers to jump in here and reply. If you need details of
>>> the approach, please jump in a call with Alex Schultz.
>>>
>>> Thank you,
>>>
>>> [1]
>>> http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-30-16.00.html
>>>
>>> On Fri, Jul 31, 2015 at 5:52 AM Vladimir Kuklin 
>>> wrote:
>>>
 Folks

 I do actively support our initiative to use librarian to be as close as
 possible to upstream, but let's not merge such invasive changes until we
 announce Hard Code Freeze and create stable/

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

[Lance Bragstad]

On Tue, Aug 4, 2015 at 9:28 AM, Boris Bobrov  wrote:

> On Tuesday 04 August 2015 08:06:21 Lance Bragstad wrote:
> > On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov 
> wrote:
> > > On Monday 03 August 2015 21:05:00 David Stanek wrote:
> > > > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov 
> > >
> > > wrote:
> > > > > Also, come on, does http://paste.openstack.org/show/406674/ look
> > > > > overly
> > > > > complex? (it should be launched from Fuel master node).
> > > >
> > > > I'm reading this on a small phone, so I may have it wrong, but the
> > > > script
> > > >
> > > > appears to be broken.
> > > >
> > > >
> > > >
> > > > It will ssh to node-1 and rotate. In the simplest case this takes key
> > > > 0
> > >
> > > and
> > >
> > > > moves it to the next highest key number. Then a new key 0 is
> > > > generated.
> > > >
> > > >
> > > >
> > > > Later there is a loop that will again ssh into node-1 and run the
> > >
> > > rotation
> > >
> > > > script. If there is a limit set on the number of keys and you are at
> > > > that
> > > >
> > > > limit a key will be deleted. This extra rotation on node-1 means that
> > >
> > > it's
> > >
> > > > possible that it has a different set of keys than are on node-2 and
> > >
> > > node-3.
> > >
> > >
> > >
> > > You are absolutely right. Node-1 should be excluded from the loop.
> > >
> > >
> > >
> > > pinc also lacks "-c 1".
> > >
> > >
> > >
> > > I am sure that other issues can be found.
> > >
> > >
> > >
> > > In my excuse I want to say that I never ran the script and wrote it
> just
> > > to show how simple it should be. Thank for review though!
> > >
> > >
> > >
> > > I also hope that no one is going to use a script from a mailing list.
> > >
> > > > What's the issue with just a simple rsync of the directory?
> > >
> > > None I think. I just want to reuse the interface provided by
> > > keystone-manage.
> >
> > You wanted to use the interface from keystone-manage to handle the actual
> > promotion of the staged key, right? This is why there were two
> > fernet_rotate commands issued?
>
> Right. Here is the fixed version (please don't use it anyway):
> http://paste.openstack.org/show/406862/


Note, this doesn't take into account the initial key repository creation,
does it?

Here is a similar version that relies on rsync for the distribution after
the initial key rotation [0].

[0] http://cdn.pasteraw.com/d6odnvtt1u9zsw5mg4xetzgufy1mjua


>
>
> --
> Best regards,
> Boris Bobrov
>
> __
> 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] Hyper-V 2008 R2 support

[Daniel P. Berrange]

On Tue, Aug 04, 2015 at 02:34:19PM +, Alessandro Pilotti wrote:
> Hi guys,
> 
> Just a quick note on the Windows editions support matrix updates for the Nova
> Hyper-V driver and Neutron networking-hyperv ML2 agent:  
> 
> We are planning to drop legacy Windows Server / Hyper-V Server 2008 R2 support
> starting with Liberty.
> 
> Windows Server / Hyper-V Server 2012 and above will continue to be supported.

What do you mean precisely by drop support here ?  Are you merely no longer
testing it, or is Nova actually broken with Hyper-V 2k8 R2  in Liberty ?

Generally if we intend to drop a hypervisor platform we'd expect to have a
deprecation period for 1 cycle where Nova would print out a warning message
on startup to alert administrators if using the platform that is intended
to be dropped. This gives them time to plan a move to a newer platform
before we drop the support.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] Would people see a value in the cve-check-tool?

[Reshetova, Elena]

Hi Adam, 

 

Thank you for your suggestion! I will send also this proposal to 
openstack-security@.

I have previously attached the wrapper python class to the email, but it seems 
that it didn’t reach people. Let me try again (now in a form of an archive) and 
see if it goes through this time. 

 

Best Regards,
Elena.

 

From: Adam Heczko [mailto:ahec...@mirantis.com] 
Sent: Monday, August 3, 2015 3:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Heath, Constanza M; Ding, Jian-feng; Demeter, Michael; Bhandaru, Malini K
Subject: Re: [openstack-dev] Would people see a value in the cve-check-tool?

 

Hi Elena, the tool looks very interesting.

Maybe try to spread out this proposal also through openstack-security@ ML.

BTW, I can't find the wrapper mentioned - am I missing something?

 

Regards,

 

Adam

 

On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena mailto:elena.reshet...@intel.com> > wrote:

Hi,

 

We would like to ask opinions if people find it valuable to include a 
cve-check-tool into the OpenStack continuous integration process? 

A tool can be run against the package and module dependencies of OpenStack 
components and detect any CVEs (in future there are also plans to integrate 
more functionality to the tool, such as scanning of other vulnerability 
databases and etc.). It would not only provide fast detection of new 
vulnerabilities that are being released for existing dependencies, but also 
control that people are not introducing new vulnerable dependencies. 

 

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

 

I am attaching an example of a very simple Python wrapper for the tool, which 
is able to process formats like: 
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt

and an example of html output if you would be running it for the python module 
requests 2.2.1 version (which is vulnerable to 3 CVEs). 

 

Best Regards,
Elena.

 

 


__
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





 

-- 

Adam Heczko

Security Engineer @ Mirantis Inc.



wrapper.zipx
Description: Binary data


smime.p7s
Description: S/MIME cryptographic 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] Would people see a value in the cve-check-tool?

[Matthew Thode]

On 08/03/2015 04:08 PM, Reshetova, Elena wrote:
> Hi,
> 
>  
> 
> We would like to ask opinions if people find it valuable to include a
> cve-check-tool into the OpenStack continuous integration process? 
> 
> A tool can be run against the package and module dependencies of OpenStack
> components and detect any CVEs (in future there are also plans to integrate
> more functionality to the tool, such as scanning of other vulnerability
> databases and etc.). It would not only provide fast detection of new
> vulnerabilities that are being released for existing dependencies, but also
> control that people are not introducing new vulnerable dependencies. 
> 
>  
> 
> The tool is located here: https://github.com/ikeydoherty/cve-check-tool
> 
>  
> 
> I am attaching an example of a very simple Python wrapper for the tool,
> which is able to process formats like:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.
> txt
> 
> and an example of html output if you would be running it for the python
> module requests 2.2.1 version (which is vulnerable to 3 CVEs). 
> 
>  
> 
> Best Regards,
> Elena.
> 
>  
> 
>  
> 
> 
> 
> 
> __
> 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
> 
As a packager I love this :D

-- 
-- Matthew Thode (prometheanfire)



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] [nova] Thoughts on things that don't make freeze cutoffs

[Sylvain Bauza]

Le 4 août 2015 13:18, "Davanum Srinivas"  a écrit :
>
> +1 to "pushing for is creating Nova subteams with their own core
> reviewers, which would be experts and trusted to +2 on a defined
> subset of code."
>
> Oslo has cores who can +2 any of the oslo libraries and each Oslo
> library has its own cores as well. We tend to elevate karma quickly
> for cores between libraries and from library core to the main core. So
> this is working well and could be something Nova can adopt. (oslo
> library == nova sub team).
>
> I used to think that subteam +2 karma with informal boundaries may be
> better, but nova cores may be more comfortable with explicit
> boundaries and karma elevation.
>
> ...But anything is better than status quo!
>
> Thanks,
> dims
>

Well, we already tried to create subteams in Liberty, so please make sure
it's not something on status quo.

That said, it's understandable that delegating trust to subteams doesn't
necessarily resolve the problem and actually proxies that to the
trustability within the team.

Are all the subteam members trusting them together ? Can we assume that we
can scale ? What could be the acceptance criterias for being a subteam
member ? How can we identify that level of acceptance ? See, there are
still unresolved questions, hence my call for waiting Tokyo on that.

-Sylvain

>
> On Tue, Aug 4, 2015 at 6:54 AM, Thierry Carrez 
wrote:
> > John Garbutt wrote:
> >> [...]
> >> Personally I find a mix of coding and reviewing good to keep a decent
> >> level of empathy and sanity. I don't have time for any coding this
> >> release (only a bit of documenting), and its not something I can
> >> honestly recommend as a best practice. If people don't maintain a good
> >> level of reviews, we do tend to drop those folks from nova-core.
> >>
> >> I know ttx has been pushing for dedicated reviewers. It would be nice
> >> to find folks that can do that, but we just haven't found any of those
> >> people to date.
> >
> > Hell no! I'd hate dedicated reviewers.
> >
> > I want everyone to be a reviewer and a commit author. It's the only way
> > to keep current on the code and relevant enough to be trusted for the
> > final +2s.
> >
> > The trick is that given how wide and diverse Nova's code is, it's
> > impossible to be a reviewer / commit author / expert in all the Nova
> > things. If you slowly grew with Nova over the past years, you may have a
> > good grasp of most parts. But for newcomers, it's an impossible mountain
> > to climb, and they prefer to go to smaller projects. And as we burn out
> > old people with a giant set of reviews, we fail to replace them with new
> > blood.
> >
> > This is why I advocate dividing code / reviewers / expertise along
> > smaller areas within Nova, so that new people can focus and become a
> > master again. What I'm pushing for is creating Nova subteams with their
> > own core reviewers, which would be experts and trusted to +2 on a
> > defined subset of code.
> >
> > --
> > 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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] A possible solution for HA Active-Active

[Joshua Harlow]

Duncan Thomas wrote:

On 3 August 2015 at 20:53, Clint Byrum mailto:cl...@fewbar.com>> wrote:

Excerpts from Devananda van der Veen's message of 2015-08-03
08:53:21 -0700:
Also on a side note, I think Cinder's need for this is really subtle,
and one could just accept that sometimes it's going to break when it
does
two things to one resource from two hosts. The error rate there might
even be lower than the false-error rate that would be caused by a
twitchy
DLM with timeouts a little low. So there's a core cinder discussion that
keeps losing to the shiny DLM discussion, and I'd like to see it played
out fully: Could Cinder just not do anything, and let the few drivers
that react _really_ badly, implement their own concurrency controls?



So the problem here is data corruption. Lots of our races can cause data
corruption. Not 'my instance didn't come up', not 'my network is screwed
and I need to tear everything down and do it again', but 'My 1tb of
customer database is now missing the second half'. This means that we
*really* need some confidence and understanding in whatever we do. The
idea of locks timing out and being stolen without fencing is frankly
scary and begging for data corruption unless we're very careful. I'd
rather use a persistent lock (e.g. a db record change) and manual
recovery than a lock timeout that might cause corruption.


So perhaps start off using persistent locks, gain confidence that we 
have all the right fixes in to prevent that data corruption, and then 
slowly remove persistent locks as needed. Sounds like an iterative 
solution to me, and one that will build confidence (hopefully that 
confidence building can be automated via a chaos-monkey like test-suite) 
as we go :)





--
Duncan Thomas

__
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] Hyper-V 2008 R2 support

[Alessandro Pilotti]

> On 04 Aug 2015, at 17:56, Daniel P. Berrange  wrote:
> 
> On Tue, Aug 04, 2015 at 02:34:19PM +, Alessandro Pilotti wrote:
>> Hi guys,
>> 
>> Just a quick note on the Windows editions support matrix updates for the Nova
>> Hyper-V driver and Neutron networking-hyperv ML2 agent:  
>> 
>> We are planning to drop legacy Windows Server / Hyper-V Server 2008 R2 
>> support
>> starting with Liberty.
>> 
>> Windows Server / Hyper-V Server 2012 and above will continue to be supported.
> 
> What do you mean precisely by drop support here ?  Are you merely no longer
> testing it, or is Nova actually broken with Hyper-V 2k8 R2  in Liberty ?
> 
> Generally if we intend to drop a hypervisor platform we'd expect to have a
> deprecation period for 1 cycle where Nova would print out a warning message
> on startup to alert administrators if using the platform that is intended
> to be dropped. This gives them time to plan a move to a newer platform
> before we drop the support.

The plan is to move the Hyper-V specific code to a new Oslo project during the
early M cycle and as part of the move the 2008 R2 specific code will be dropped.
This refers to the OS specific interaction layer (the *utils modules)
which are mostly shared across multiple projects (nova, cinder,
networking-hyperv, ceilometer, etc).

Contextually the corresponding code will be proposed for removal in Nova,
replacing it with the new oslo dependency.

The 2008 R2 code will still be available in Liberty, although untested.
A deprecation warning can surely be added to the logs.

Alessandro

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
> 
> __
> 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] weekly meeting #45

[Emilien Macchi]

On 08/03/2015 04:31 PM, Emilien Macchi wrote:
> 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-20150804
> 
> Please add additional items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.
> 
> See you there!

We did our meeting, you can read notes here:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-08-04-15.00.html

Have a great day,
-- 
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] [Cinder] A possible solution for HA Active-Active

[Joshua Harlow]

Philipp Marek wrote:

If we end up using a DLM then we have to detect when the connection to
the DLM is lost on a node and stop all ongoing operations to prevent
data corruption.

It may not be trivial to do, but we will have to do it in any solution
we use, even on my last proposal that only uses the DB in Volume Manager
we would still need to stop all operations if we lose connection to the
DB.


Well, is it already decided that Pacemaker would be chosen to provide HA in
Openstack? There's been a talk "Pacemaker: the PID 1 of Openstack" IIRC.

I know that Pacemaker's been pushed aside in an earlier ML post, but IMO
there's already *so much* been done for HA in Pacemaker that Openstack
should just use it.

All HA nodes needs to participate in a Pacemaker cluster - and if one node
looses connection, all services will get stopped automatically (by
Pacemaker) - or the node gets fenced.


No need to invent some sloppy scripts to do exactly the tasks (badly!) that
the Linux HA Stack has been providing for quite a few years.


Yes, Pacemaker needs learning - but not more than any other involved
project, and there are already quite a few here, which have to be known to
any operator or developer already.


(BTW, LINBIT sells training for the Linux HA Cluster Stack - and yes,
  I work for them ;)


So just a piece of information, but yahoo (the company I work for, with 
vms in the tens of thousands, baremetal in the much more than that...) 
hasn't used pacemaker, and in all honesty this is the first project 
(openstack) that I have heard that needs such a solution. I feel that we 
really should be building our services better so that they can be A-A vs 
having to depend on another piece of software to get around our 
'sloppiness' (for lack of a better word).


Nothing against pacemaker personally... IMHO it just doesn't feel like 
we are doing this right if we need such a product in the first place.




__
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] A possible solution for HA Active-Active

[Joshua Harlow]

Clint Byrum wrote:

Excerpts from Devananda van der Veen's message of 2015-08-03 08:53:21 -0700:

On Mon, Aug 3, 2015 at 8:41 AM Joshua Harlow  wrote:


Clint Byrum wrote:

Excerpts from Gorka Eguileor's message of 2015-08-02 15:49:46 -0700:

On Fri, Jul 31, 2015 at 01:47:22AM -0700, Mike Perez wrote:

On Mon, Jul 27, 2015 at 12:35 PM, Gorka Eguileor

wrote:

I know we've all been looking at the HA Active-Active problem in

Cinder

and trying our best to figure out possible solutions to the different
issues, and since current plan is going to take a while (because it
requires that we finish first fixing Cinder-Nova interactions), I've

been

looking at alternatives that allow Active-Active configurations

without

needing to wait for those changes to take effect.

And I think I have found a possible solution, but since the HA A-A
problem has a lot of moving parts I ended up upgrading my initial
Etherpad notes to a post [1].

Even if we decide that this is not the way to go, which we'll probably
do, I still think that the post brings a little clarity on all the
moving parts of the problem, even some that are not reflected on our
Etherpad [2], and it can help us not miss anything when deciding on a
different solution.

Based on IRC conversations in the Cinder room and hearing people's
opinions in the spec reviews, I'm not convinced the complexity that a
distributed lock manager adds to Cinder for both developers and the
operators who ultimately are going to have to learn to maintain things
like Zoo Keeper as a result is worth it.

**Key point**: We're not scaling Cinder itself, it's about scaling to
avoid build up of operations from the storage backend solutions
themselves.

Whatever people think ZooKeeper "scaling level" is going to accomplish
is not even a question. We don't need it, because Cinder isn't as
complex as people are making it.

I'd like to think the Cinder team is a great in recognizing potential
cross project initiatives. Look at what Thang Pham has done with
Nova's version object solution. He made a generic solution into an
Oslo solution for all, and Cinder is using it. That was awesome, and
people really appreciated that there was a focus for other projects to
get better, not just Cinder.

Have people consider Ironic's hash ring solution? The project Akanda
is now adopting it [1], and I think it might have potential. I'd
appreciate it if interested parties could have this evaluated before
the Cinder midcycle sprint next week, to be ready for discussion.

[1] - https://review.openstack.org/#/c/195366/

-- Mike Perez

Hi all,

Since my original proposal was more complex that it needed be I have a
new proposal of a simpler solution, and I describe how we can do it with
or without a DLM since we don't seem to reach an agreement on that.

The solution description was more rushed than previous one so I may have
missed some things.

http://gorka.eguileor.com/simpler-road-to-cinder-active-active/


I like the idea of keeping it simpler Gorka. :)

Note that this is punting back to "use the database for coordination",
which is what most projects have done thus far, and has a number of
advantages and disadvantages.

Note that the stale-lock problem was solved in an interesting way in

Heat:

each engine process gets an "instance-of-engine" uuid that adds to the
topic queues it listens to. If it holds a lock, it records this UUID in
the owner field. When somebody wants to steal the lock (due to timeout)
they send to this queue, and if there's no response, the lock is stolen.

Anyway, I think what might make more sense than copying that directly,
is implementing "Use the database and oslo.messaging to build a DLM"
as a tooz backend. This way as the negative aspects of that approach
impact an operator, they can pick a tooz driver that satisfies their
needs, or even write one to their specific backend needs.

Oh jeez, using 'the database and oslo.messaging to build a DLM' scares
me :-/

There are already N + 1 DLM like-systems out there (and more every day
if u consider the list at
https://raftconsensus.github.io/#implementations) so I'd really rather
use one that is proven to work by academia vs make a frankenstein one.



Joshua,

As has been said on this thread, some projects (eg, Ironic) are already
using a consistent hash ring backed by a database to meet the requirements
they have. Could those requirements also be met with some other tech? Yes.
Would that provide additional functionality or some other benefits? Maybe.
But that's not what this thread was about.

Distributed hash rings are a well understood technique, as are databases.
There's no need to be insulting by calling
not-your-favorite-technology-of-the-day a frankenstein one.

The topic here, which I've been eagerly following, is whether or not Cinder
needs to use a DLM *at all*. Until that is addressed, discussing specific
DLM or distributed KVS is not necessary.



The hash ring has its own set of problems and it is not a magic pill. As

Re: [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Carl Baldwin]

On Mon, Aug 3, 2015 at 9:07 PM, Mike Dorman  wrote:
> I hope we can move this idea moving forward.  I was disappointed to see
> the spec abandoned.

While I think the ship has sailed for Liberty, this is going to be my
top priority for for Mitaka.  Abandoning the spec may have sent the
wrong message.  It was partly because my list of open reviews was
longer than I wanted and partly because I need to go back to the
drawing board (this may have let some frustration show through).
Maybe keeping it in WIP or with my own -2 would've been more
appropriate.  I forget sometimes that the actions I take on my own
reviews can be interpreted differently than what I was thinking when I
took them.

This thread has made it clear to me that I need to reconsider a few
perspectives.

> Some of us from the large deployers group will be at the Ops Meetup.  Will
> there be any representation from Neutron there that we could discuss with
> more?

I don't think that I can manage to get to the operators meetup but I
would like to attend it with a remote option as mentioned later in
this thread.

Carl

__
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] Does OpenStack need a common solution for DLM?

[Joshua Harlow]

Flavio Percoco wrote:

On 03/08/15 19:48 +0200, Gorka Eguileor wrote:

On Mon, Aug 03, 2015 at 03:42:48PM +, Fox, Kevin M wrote:

I'm usually for abstraction layers, but they don't always pay off
very well due to catering to the lowest common denominator.

Lets clearly define the problem space first. IFF the problem space
can be fully implemented using Tooz, then lets do that. Then the
operator can choose. If Tooz cant and wont handle the problem space,
then we're trying to fit a square peg in a round hole.


What do you mean with clearly define the problem space? We know what we
want, we just need to agree on the compromises we are willing to make,
use a DLM and make admins' life a little harder (only for those that
deploy A-A) but have an A-A solution earlier, or postpone A-A
functionality but make their life easier.

And we already know that Tooz is not the Holy Grail and will not perform
the miracle of giving Cinder HA A-A. It is only a piece of the problem,
so there's nothing to discuss there, and it's not a square peg on a
round hole, because it fits perfectly for what it is intended. But once
you have filled that square hole you need another peg, the round one for
the round hole.

If people are expecting to find one thing that fixes everything and
gives us HA A-A on its own, then I believe they are a little bit lost.


As confusing as it seems, we've now moved from talking about just
Cinder to understanding whether this is a problem many projects have
and whether we can find a solution that will work for most of them.
Therefore, I've renamed this thread to make this more evident.

Now, so far we have:

- Ironic has an internal distributed lock and it uses a hash-ring
- Ceilometer uses tooz
- Several projects use a file lock of some other fashion of
distributed lock.
- *Add yours here*

Each one of these projects has a specific use-case that doesn't
necessarily overlap. I'd like to see those cases listed somewhere.
We've done this in the past already and I believe we can do it now as
well. As I've mentioned in another thread, Gorka has done this for
Cinder already now we need to do it for other services too. Even if
your project has a DLM in place, it'd be good to know what problem you
solved with it as it may be a problem that other projects have as
well.

As a community, we've been able to do away with adding a new service
for DLM's thus far. I'm not saying we don't need one but, as mentioned
in other threads, lets give this some more thought before we add a new
service that'll make deploying and maintaining OpenStack harder.



On the contrary, I think it would make deploying and maintaining 
openstack easier... As each service implements its own DLM pieces this 
means that they all do it in a way that is different from each other, 
which actually makes the situation worse (now operators needs to figure 
out the X different ways this was done, the X different ways to release 
a messed up/stale/other lock...). DLM(s) like zookeeper and others 
provide that 'single' way of doing it (they also provide introspection 
abilities, ie to see who is waiting on a lock, what connection has a 
lock...) so IMHO I feel the question of should we has really already 
been passed (but others may disagree).



Flavio


From: Gorka Eguileor [gegui...@redhat.com]
Sent: Monday, August 03, 2015 1:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
Active-Active

On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> Flavio Percoco wrote:
> > [...]
> > So, to summarize, I love the effort behind this. But, as others have
> > mentioned, I'd like us to take a step back, run this accross
teams and
> > come up with an opinonated solution that would work for everyone.
> >
> > Starting this discussion now would allow us to prepare enough
material
> > to reach an agreement in Tokyo and work on a single solution for
> > Mikata. This sounds like a good topic for a cross-project session.
>
> +1
>
> The last thing we want is to rush a solution that would only solve a
> particular project use case. Personally I'd like us to pick the
simplest
> solution that can solve most of the use cases. Each of the solutions
> bring something to the table -- Zookeeper is mature, Consul is
> featureful, etcd is lean and simple... Let's not dive into the best
> solution but clearly define the problem space first.
>
> --
> Thierry Carrez (ttx)
>

I don't see those as different solutions from the point of view of
Cinder, they are different implementations to the same solution case,
using a DLM to lock resources.

We keep circling back to the fancy names like moths to a flame, when we
are still discussing whether we need or want a DLM for the solution. I
think we should stop doing that, we need to decide on the solution from
an abstract point of view (like you say, define the problem space) and
not get caught up on discussions of which one of those is be

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Douglas Fish]

Hi David,

This is a cool looking UI. I've made a minor comment on it in InVision.

I'm curious if this is an implementable idea - does keystone support large
numbers of 3rd party idps? is there an API to retreive the list of idps or
does this require carefully coordinated configuration between Horizon and
Keystone so they both recognize the same list of idps?

Doug Fish


David Chadwick  wrote on 08/01/2015 06:01:48 AM:

> From: David Chadwick 
> To: OpenStack Development Mailing List

> Date: 08/01/2015 06:05 AM
> Subject: [openstack-dev]  [Keystone] [Horizon] Federated Login
>
> Hi Everyone
>
> I have a student building a GUI for federated login with Horizon. The
> interface supports both a drop down list of configured IDPs, and also
> Type Ahead for massive federations with hundreds of IdPs. Screenshots
> are visible in InVision here
>
> https://invis.io/HQ3QN2123
>
> All comments on the design are appreciated. You can make them directly
> to the screens via InVision
>
> Regards
>
> David
>
>
>
>
__
> 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] Let's talk about API versions

[Jim Rollenhagen]

On Mon, Jul 27, 2015 at 01:35:25PM -0700, Jim Rollenhagen wrote:
> 
> Now we've landed a patch[0] with a new version (1.11) that is not
> backward compatible. It causes newly added Node objects to begin life in
> the ENROLL state, rather than AVAILABLE. This is a good thing, and
> people should want this! However, it is a breaking change. Automation
> that adds nodes to Ironic will need to do different things after the
> node-create call.
> 
> Our API versioning scheme makes this opt-in (by specifying the API
> version). However, some folks have a problem with releasing this change
> as-is. The logic is that we might release a client that defaults to 1.11
> or higher, or the user may request 1.12 later to get a new feature, thus
> breaking their application that enrolls nodes.

So after much deliberation, we took an informal vote in IRC this morning
between 5 out of our 9 cores.

The question was: "should we do a 1.12 api version that allows the user
to pick begining provision state in (AVAILABLE, ENROLL), defaulting to
AVAILABLE?"

The results were 3 for no, 2 for yes. So that's the plan.

Other Ironic cores (Haomeng, Yuriy, Ramesh, Ruby): please chime in if
you have opinions on this. :)

Otherwise we'll be getting to work on releasing a server as-is in the
next few days.

// 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

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[David Chadwick]

Hi Doug

On 04/08/2015 16:52, Douglas Fish wrote:
> Hi David,
> 
> This is a cool looking UI. I've made a minor comment on it in InVision.

thanks

> 
> I'm curious if this is an implementable idea 

It has to be, since there are many existing federations with 100s of
IDPs. Simply displaying a list is not usable in this environment.
There are many SPs that implement this sort of interface today. Eg. the
UK Access Management federation has hundreds of members, see

http://www.ukfederation.org.uk/content/Documents/MemberList


- does keystone support large
> numbers of 3rd party idps?

It should. I dont know of anyone who has done scalability testing, but I
dont think the design has any inbuilt constraints

 is there an API to retreive the list of idps

yes

or
> does this require carefully coordinated configuration between Horizon and
> Keystone so they both recognize the same list of idps?

No, Horizon uses the Keystone API

regards
David

> 
> Doug Fish
> 
> 
> David Chadwick  wrote on 08/01/2015 06:01:48 AM:
> 
>> From: David Chadwick 
>> To: OpenStack Development Mailing List
> 
>> Date: 08/01/2015 06:05 AM
>> Subject: [openstack-dev]  [Keystone] [Horizon] Federated Login
>>
>> Hi Everyone
>>
>> I have a student building a GUI for federated login with Horizon. The
>> interface supports both a drop down list of configured IDPs, and also
>> Type Ahead for massive federations with hundreds of IdPs. Screenshots
>> are visible in InVision here
>>
>> https://invis.io/HQ3QN2123
>>
>> All comments on the design are appreciated. You can make them directly
>> to the screens via InVision
>>
>> Regards
>>
>> David
>>
>>
>>
>>
> __
>> 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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Clark Boylan]

On Tue, Aug 4, 2015, at 06:22 AM, Doug Hellmann wrote:
> Excerpts from Clark Boylan's message of 2015-08-03 11:54:06 -0700:
> > On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
> > > Hi everyone,
> > > 
> > > A month ago the stable branch team decided to move away from
> > > synchronized stable point releases and enable continuous stable branch
> > > delivery instead.
> > > 
> > > The end goal is that every commit on a stable branch for a "service"
> > > project will get a .Z version increment, and a tag be pushed to match.
> > > So we'll have for example Nova 12.0.0 at Liberty release, and each
> > > stable branch commit will result in 12.0.1, 12.0.2... versions.
> > > 
> > > In order to make this work, it looks like we'd require:
> > > 
> > > * pbr changes so that it supports a mode where every commit on the
> > > branch increments .Z
> > > 
> > > * infra changes to automatically push the corresponding tag when the
> > > commit is merged
> > > 
> > > To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80
> > > (kilo) and Nova 10.0.218 (juno).
> > I am not a fan of doing this second option at all. We would be polluting
> > the ref space of our repos with redundant information making the output
> > of `git tag` unusable to humans. If this was not redundant info and a
> > tag of 11.0.80 provided more information than a generated version of
> > 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.
> 
> One problem with dev versions that has been pointed out elsewhere
> (by ttx?) is that it is difficult/impossible to distinguish between
> 11.0.0.dev80 on stable/kilo and a my-companys-patched/kilo branch,
> since we're counting commits but the version doesn't actually depend
> on the contents of those commits. Using explicit tags in our repo
> endows those versions with a bit more "officialness".
> 
> I'm not sure why you see having more tags "polluting" the ref space, can
> you elaborate on that?
> 
Sure, if we continue to use nova as the example, the current total
number of tags present is:

clark@morbo:~/src/openstack/nova (master)$ git tag | wc -l
89

Which means for a single stable release we would more than double the
total number of tags in the repo. Going from 89 tags to 387 tags without
any additional information associated to those tags beyond "new commit"
pollutes the tag ref space for humans. A computer can deal with 387 tags
trivially, but it is harder for me to do so.

Clark

__
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] [Neutron] VPNaaS and DVR compatibility

[Sergey Kolekonov]

Hi,

I'd like to clarify a situation around VPNaaS and DVR compatibility in
Neutron.
In non-DVR case VMs use a network node to access each other and external
network.
So with VPNaaS enabled we just have additional setup steps performed on
network nodes to establish VPN connection between VMs.
With DVR enabled two VMs from different networks (or even clouds) should
still reach each other through network nodes, but if floating IPs are
assigned, this doesn't work.
So my question is: is it expected and if yes are there any plans to add
full support for VPNaaS on DVR-enabled clusters?

Thank you.
-- 
Regards,
Sergey Kolekonov
__
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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2015-08-04 09:28:00 -0700:
> 
> On Tue, Aug 4, 2015, at 06:22 AM, Doug Hellmann wrote:
> > Excerpts from Clark Boylan's message of 2015-08-03 11:54:06 -0700:
> > > On Mon, Aug 3, 2015, at 05:46 AM, Thierry Carrez wrote:
> > > > Hi everyone,
> > > > 
> > > > A month ago the stable branch team decided to move away from
> > > > synchronized stable point releases and enable continuous stable branch
> > > > delivery instead.
> > > > 
> > > > The end goal is that every commit on a stable branch for a "service"
> > > > project will get a .Z version increment, and a tag be pushed to match.
> > > > So we'll have for example Nova 12.0.0 at Liberty release, and each
> > > > stable branch commit will result in 12.0.1, 12.0.2... versions.
> > > > 
> > > > In order to make this work, it looks like we'd require:
> > > > 
> > > > * pbr changes so that it supports a mode where every commit on the
> > > > branch increments .Z
> > > > 
> > > > * infra changes to automatically push the corresponding tag when the
> > > > commit is merged
> > > > 
> > > > To give you an idea, if we enabled that for Kilo we'd be at Nova 11.0.80
> > > > (kilo) and Nova 10.0.218 (juno).
> > > I am not a fan of doing this second option at all. We would be polluting
> > > the ref space of our repos with redundant information making the output
> > > of `git tag` unusable to humans. If this was not redundant info and a
> > > tag of 11.0.80 provided more information than a generated version of
> > > 11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.
> > 
> > One problem with dev versions that has been pointed out elsewhere
> > (by ttx?) is that it is difficult/impossible to distinguish between
> > 11.0.0.dev80 on stable/kilo and a my-companys-patched/kilo branch,
> > since we're counting commits but the version doesn't actually depend
> > on the contents of those commits. Using explicit tags in our repo
> > endows those versions with a bit more "officialness".
> > 
> > I'm not sure why you see having more tags "polluting" the ref space, can
> > you elaborate on that?
> > 
> Sure, if we continue to use nova as the example, the current total
> number of tags present is:
> 
> clark@morbo:~/src/openstack/nova (master)$ git tag | wc -l
> 89
> 
> Which means for a single stable release we would more than double the
> total number of tags in the repo. Going from 89 tags to 387 tags without
> any additional information associated to those tags beyond "new commit"
> pollutes the tag ref space for humans. A computer can deal with 387 tags
> trivially, but it is harder for me to do so.

Using pbr to generate versions avoids that problem, but introduces the
challenge of not being able to necessarily figure out which commit
corresponds to a given version number from the outside. Say I want to
check out version 11.0.80 for some reason (maybe .81 has a bug I don't
want to deploy). How do I do that without a tag?

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] [Keystone] [Horizon] Federated Login

[Lin Hua Cheng]

Hi David,

There was a similar effort in Kilo to design the flow in the login page for
federated login[1].   WebSSO feature[2] was implemented in Kilo, it allows
the user to perform federated login by selecting an IdP protocol.  This
have tested with kerberos and saml2.

There is a proposal to extend that feature to show listing per Idp/Protocol
instead [3], because just listing only by protocol is fairly limited .

I think the Type Ahead can fit it nicely when we implement the support for
WebSSO by IdP/Protocol.

thanks,
Lin

[1] https://openstack.invisionapp.com/d/main#/projects/2784587
[2] http://docs.openstack.org/developer/keystone/extensions/websso.html
[3] https://review.openstack.org/#/c/199339/


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

On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick 
wrote:

> Hi Everyone
>
> I have a student building a GUI for federated login with Horizon. The
> interface supports both a drop down list of configured IDPs, and also
> Type Ahead for massive federations with hundreds of IdPs. Screenshots
> are visible in InVision here
>
> https://invis.io/HQ3QN2123
>
> All comments on the design are appreciated. You can make them directly
> to the screens via InVision
>
> Regards
>
> David
>
>
>
> __
> 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] [nfv][telco] Meeting canceled 2015-08-05

[Steve Gordon]

Hi all,

I am traveling and unable to facilitate the Telco Working Group meeting this 
week and was unable to find a backup, as such the meeting is canceled fro 
2015-08-05 (Wednesday).

Thanks!

Steve

__
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] [Neutron][L3] Representing a networks connected by routers

[Kevin Benton]

>You're right but in the current model you can't have IP addresses without
the network either which is actually the point I'm trying to make.

Definitely, but it's not because the network has properties that IPAM
depends on. It's only because a subnet has a non-nullable foreign key
relationship to a network. The network itself doesn't have anything IPAM
depends on.

>This sounds about right.  I think it is wrong to assume that we need an L2
network to encapsulate L3 things.  I'm feeling restricted by the model and
the insistence that a neutron network is a purely L2 construct.

I agree that it's wrong to assume we need L2 in the model for L3 stuff.
Let's fix that by taking away the requirement for the L2 component, which
is the network.

>Notice that a network marked only as external doesn't allow normal tenants
to create ports.

It does if the owner is a normal tenant. An admin (or a service tenant
permitted by policy.json) also can as well, which is particularly relevant
when you run service VMs in the external network (or VMs as routers).

>The bad assumption here is that floating IPs need an explicit association
with an L2 only construct:  tenant's allocate a floating IP by selecting
the Neutron network it is recorded in the DB that way.

I agree, but lets fix it by taking the floating IP off of the network. Not
by trying to strip l2 out of the network for this one case.

>These are the factors that make me view the Neutron network as an L2 + L3
construct.

I just view it as an indication that we were missing a way to reference a
group of subnets.

>Is this really so different from what I'm trying to do with networks? Make
the L2 part nullable.

I think so, the difference is that I just want to eliminate a dependency
between the objects. The L3 networks proposal essentially nullifies
everything in the network except for the subnets it contains. There is
nothing L3 related in a network except for those subnets.

>In your model, should the port be associated with the "group of subnets"
at all?  I'm not sure I see a need for it to be directly associated but I
haven't thought it all the way through.

Probably not. It would just be a part of the creation request where you
could say that you want it allocated from a group of subnets. The actual
association would just be to a specific subnet in the fixed_ip field I
think.

>All the ports are still connected to L2 network segments so I don't think
this is an issue.

I was mixing your spec with Neil's needs as well. I had thought we were
trying to solve both (which is what I want to do if we can). For his case,
ports need to be directly associated to these new non-L2 things.

>I'm willing to discuss this further.  In fact, it has been on my mind for
a while now.  This is essentially where I started.  I ended up with my
current proposal because I perceived a lot more difficulty in doing this
than in the proposal I created.  But, your perspective from the other side
of the problem is worth considering.

I definitely see why you chose this path. I was even in agreement with it
at the mid-cycle where we were thinking of using a provider network type of
L3. But the more I've been looking through ML2 and the provider networks
stuff to see how it would fit, the more I realized how much we are going to
have to special-case this one particular type.

I see that you abandoned the spec for this cycle, but maybe we can still
put something together towards the end of the cycle...

On Mon, Aug 3, 2015 at 2:27 PM, Carl Baldwin  wrote:

> Kevin, sorry for the delay in response.  Keeping up on this thread was
> getting difficult while on vacation.
>
> tl;dr:  I think it is worth it to talk through the idea of inserting
> some sort of a "subnet group thing" in the model to which floating ips
> (and router external gateways) will associate.  It has been on my mind
> for a long time now.  I didn't pursue it because a few informal
> attempts to discuss it with others indicated to me that it would be a
> difficult heavy-lifting job that others may not appreciate or
> understand.  Scroll to the bottom of this message for a little more on
> this.
>
> Carl
>
> On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton  wrote:
> >>Also, in my proposal, it is more the router that is the grouping
> mechanism.
> >
> > I can't reconcile this with all of the points you make in the rest of
> your
> > email. You want the collection of subnets that a network represents, but
> you
> > don't want any other properties of the network.
>
> This is closer to what I'm trying to say but isn't quite there.  There
> are some subnets that should be associated with the segments
> themselves and there are some that should be associated with the
> collection of segments.  I want floating IPs that are not tied the an
> L2 network.  None of the alternate proposals that I'd heard addressed
> this.
>
> >>that the network object is currently the closest thing we have to
> >> representing the L3 part of the network.
> >
> > Th

[openstack-dev] [Magnum] Networking Subteam Meeting Update

[Daneyon Hansen (danehans)]

All,

This week’s Magnum Networking Subteam Meeting will be canceled due to the 
Midcycle [1]. Sub team meetings [2] will resume on 8/13 at 1800 UTC. We have 
two container networking sessions on the midcycle agenda. WebEx has been setup 
if you would like to attend the midcycle remotely. We look forward to your 
participation at the midcycle and future subteam meetings.

[1] https://wiki.openstack.org/wiki/Magnum/Midcycle
[2] 
https://wiki.openstack.org/wiki/Meetings/Containers#Container_Networking_Subteam_Meeting

Regards,
Daneyon
__
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] A possible solution for HA Active-Active

[Clint Byrum]

Excerpts from Duncan Thomas's message of 2015-08-04 00:32:40 -0700:
> On 3 August 2015 at 20:53, Clint Byrum  wrote:
> 
> > Excerpts from Devananda van der Veen's message of 2015-08-03 08:53:21
> > -0700:
> > Also on a side note, I think Cinder's need for this is really subtle,
> > and one could just accept that sometimes it's going to break when it does
> > two things to one resource from two hosts. The error rate there might
> > even be lower than the false-error rate that would be caused by a twitchy
> > DLM with timeouts a little low. So there's a core cinder discussion that
> > keeps losing to the shiny DLM discussion, and I'd like to see it played
> > out fully: Could Cinder just not do anything, and let the few drivers
> > that react _really_ badly, implement their own concurrency controls?
> >
> 
> 
> So the problem here is data corruption. Lots of our races can cause data
> corruption. Not 'my instance didn't come up', not 'my network is screwed
> and I need to tear everything down and do it again', but 'My 1tb of
> customer database is now missing the second half'. This means that we
> *really* need some confidence and understanding in whatever we do. The idea
> of locks timing out and being stolen without fencing is frankly scary and
> begging for data corruption unless we're very careful. I'd rather use a
> persistent lock (e.g. a db record change) and manual recovery than a lock
> timeout that might cause corruption.
> 

Thanks Duncan. Can you be more specific about a known data-corrupting
race that a) isn't handled simply by serialization in the database,
and b) isn't specific to a single driver?

__
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] [Keystone] [Horizon] Federated Login

[Lance Bragstad]

On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish  wrote:

> Hi David,
>
> This is a cool looking UI. I've made a minor comment on it in InVision.
>
> I'm curious if this is an implementable idea - does keystone support large
> numbers of 3rd party idps? is there an API to retreive the list of idps or
> does this require carefully coordinated configuration between Horizon and
> Keystone so they both recognize the same list of idps?
>
>
There is an API call for getting a list of Identity Providers from Keystone

http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers



> Doug Fish
>
>
> David Chadwick  wrote on 08/01/2015 06:01:48 AM:
>
> > From: David Chadwick 
> > To: OpenStack Development Mailing List
> 
> > Date: 08/01/2015 06:05 AM
> > Subject: [openstack-dev]  [Keystone] [Horizon] Federated Login
> >
> > Hi Everyone
> >
> > I have a student building a GUI for federated login with Horizon. The
> > interface supports both a drop down list of configured IDPs, and also
> > Type Ahead for massive federations with hundreds of IdPs. Screenshots
> > are visible in InVision here
> >
> > https://invis.io/HQ3QN2123
> >
> > All comments on the design are appreciated. You can make them directly
> > to the screens via InVision
> >
> > Regards
> >
> > David
> >
> >
> >
> >
> __
> > 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] [mistral] [murano] An online YAQL evaluator

[Dmitri Zimine]

Awesome! Really.

Thank you folks for doing this. 

I am so much looking forward to moving it to 1.0 with more built-in functions 
and more power to extend it...

Note that Mistral has a few extensions, like `str`, `len`, which are not in the 
scope of evaluator.

DZ> 


On Aug 2, 2015, at 12:44 PM, Stan Lagun  wrote:

> Guys, this is awesome!!!
> 
> Happy to see yaql gets attention. One more initiative that you may find 
> interesting is https://review.openstack.org/#/c/159905/
> This is an attempt to port yaql 1.0 from Python to JS so that the same can be 
> done in browser
> 
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
> 
> 
> On Sun, Aug 2, 2015 at 5:30 PM, Nikolay Makhotkin  
> wrote:
> Hi guys! 
> 
> That's awesome! It is very useful for all us!
> 
> -- 
> Best Regards,
> Nikolay
> 
> __
> 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] [Cinder] A possible solution for HA Active-Active

[Fox, Kevin M]

Ah. Ok. Thanks.
Kevin

From: Gorka Eguileor [gegui...@redhat.com]
Sent: Tuesday, August 04, 2015 6:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] A possiblesolutionfor 
HA  Active-Active

On Tue, Aug 04, 2015 at 09:28:58AM +, Fox, Kevin M wrote:
> Its been explained for Cinder, but not for other OpenStack projects that also 
> have needs in this area.
>

For that, Flavio started a new thread "Does OpenStack need a common
solution for DLM?"

We are discussing Cinder specifics on this thread.

Cheers,
Gorka.

> Thanks,
> Kevin
>
> 
> From: Gorka Eguileor
> Sent: Tuesday, August 04, 2015 1:39:07 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Cinder] A possible solution for HA Active-Active
>
> On Mon, Aug 03, 2015 at 06:12:23PM +, Fox, Kevin M wrote:
> > For example, to parallel the conversation with databases:
> >
> > "We want a database". Well, that means mongodb, postgres, mysql, 
> > berkeleydb, etc
> >
> > "Oh, well, I need it to be a relational db", Well, that means postgresq, 
> > mysql, etc
> >
> > "Oh, and I need recursive queries"... that excludes even more.
> >
> > We are pretty sure "We want a distributed lock manager". What problems are 
> > we trying to solve using it, and what features do they require in the 
> > DLM/DLM Abstraction of choice? That will exclude some of them. It also may 
> > exclude abstraction layers that don't expose the features needed. 
> > (Recursive queries for example)
> >
> > Thanks,
> > Kevin
> > 
>
> Kevin all that has already been explained:
>
> http://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/
> http://gorka.eguileor.com/simpler-road-to-cinder-active-active/
>
> As well as on IRC and this thread, I don't see the point of repeating it
> over and over again, at some point people need to start doing their
> homework and read what's already been said to get up to speed on the
> topic so we can move on.
>
> Gorka.
>
> > From: Gorka Eguileor [gegui...@redhat.com]
> > Sent: Monday, August 03, 2015 10:48 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Cinder] A possible solution for   HA  
> > Active-Active
> >
> > On Mon, Aug 03, 2015 at 03:42:48PM +, Fox, Kevin M wrote:
> > > I'm usually for abstraction layers, but they don't always pay off very 
> > > well due to catering to the lowest common denominator.
> > >
> > > Lets clearly define the problem space first. IFF the problem space can be 
> > > fully implemented using Tooz, then lets do that. Then the operator can 
> > > choose. If Tooz cant and wont handle the problem space, then we're trying 
> > > to fit a square peg in a round hole.
> >
> > What do you mean with clearly define the problem space?  We know what we
> > want, we just need to agree on the compromises we are willing to make,
> > use a DLM and make admins' life a little harder (only for those that
> > deploy A-A) but have an A-A solution earlier, or postpone A-A
> > functionality but make their life easier.
> >
> > And we already know that Tooz is not the Holy Grail and will not perform
> > the miracle of giving Cinder HA A-A.  It is only a piece of the problem,
> > so there's nothing to discuss there, and it's not a square peg on a
> > round hole, because it fits perfectly for what it is intended. But once
> > you have filled that square hole you need another peg, the round one for
> > the round hole.
> >
> > If people are expecting to find one thing that fixes everything and
> > gives us HA A-A on its own, then I believe they are a little bit lost.
> >
> > Gorka.
> >
> > >
> > > Thanks,
> > > Kevin
> > > 
> > > From: Gorka Eguileor [gegui...@redhat.com]
> > > Sent: Monday, August 03, 2015 1:43 AM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
> > > Active-Active
> > >
> > > On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> > > > Flavio Percoco wrote:
> > > > > [...]
> > > > > So, to summarize, I love the effort behind this. But, as others have
> > > > > mentioned, I'd like us to take a step back, run this accross teams and
> > > > > come up with an opinonated solution that would work for everyone.
> > > > >
> > > > > Starting this discussion now would allow us to prepare enough material
> > > > > to reach an agreement in Tokyo and work on a single solution for
> > > > > Mikata. This sounds like a good topic for a cross-project session.
> > > >
> > > > +1
> > > >
> > > > The last thing we want is to rush a solution that would only solve a
> > > > particular project use case. Personally I'd like us to pick the simplest
> > > > solution that can solve most of th

Re: [openstack-dev] [Keystone] [Horizon] Federated Login

[Steve Martinelli]

Right, but that API is/should be protected. If we want to list IdPs
*before* authenticating a user, we either need: 1) a new API for listing
public IdPs or 2) a new policy that doesn't protect that API.

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Lance Bragstad 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2015/08/04 01:49 PM
Subject:Re: [openstack-dev] [Keystone] [Horizon] Federated Login





On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish  wrote:
  Hi David,

  This is a cool looking UI. I've made a minor comment on it in InVision.

  I'm curious if this is an implementable idea - does keystone support
  large
  numbers of 3rd party idps? is there an API to retreive the list of idps
  or
  does this require carefully coordinated configuration between Horizon and
  Keystone so they both recognize the same list of idps?


There is an API call for getting a list of Identity Providers from Keystone

http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers


  Doug Fish


  David Chadwick  wrote on 08/01/2015 06:01:48 AM:

  > From: David Chadwick 
  > To: OpenStack Development Mailing List
  
  > Date: 08/01/2015 06:05 AM
  > Subject: [openstack-dev]  [Keystone] [Horizon] Federated Login
  >
  > Hi Everyone
  >
  > I have a student building a GUI for federated login with Horizon. The
  > interface supports both a drop down list of configured IDPs, and also
  > Type Ahead for massive federations with hundreds of IdPs. Screenshots
  > are visible in InVision here
  >
  > https://invis.io/HQ3QN2123
  >
  > All comments on the design are appreciated. You can make them directly
  > to the screens via InVision
  >
  > Regards
  >
  > David
  >
  >
  >
  >
  __

  > 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] [Magnum] Container Networking Spec

[Daneyon Hansen (danehans)]

All,

The container networking spec below has gone through a fairly significant 
design change in the past few days. To summarize, Magnum will not create any 
new network plugins or network-specific abstractions to support container 
networking. Instead, the spec suggests standardizing on libnetwork [4] and its 
associated Container Network Model to support a range of container networking 
implementations. The Magnum community intends to integrate with Kuryr [5] in 
the long-term and both communities are starting the integration planning 
process [6].

I would like to thank everyone who provided feedback on the spec. If you have 
provided feedback to earlier patch sets, I ask that you review the latest patch 
set and provide an updated vote. If you issue a -1 vote, please include 
specific feedback on what is needed for your +1/+2 vote.

[4] https://github.com/docker/libnetwork/blob/master/docs/design.md
[5] https://github.com/openstack/kuryr/blob/master/doc/source/design.rst
[6] https://etherpad.openstack.org/p/magnum-kuryr

Regards,
Daneyon

From: Cisco Employee mailto:daneh...@cisco.com>>
Date: Wednesday, July 22, 2015 at 9:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Magnum] Container Networking Spec

All,

I have just submitted the container networking spec[1] for review. Thank you to 
everyone [2-3] who participated in contributing to the spec. If you are 
interested in container networking within Magnum, I urge you to review the spec 
and provide your feedback.

[1] https://review.openstack.org/#/c/204686
[2] 
http://eavesdrop.openstack.org/meetings/container_networking/2015/container_networking.2015-06-25-18.00.html
[3] 
http://eavesdrop.openstack.org/meetings/container_networking/2015/container_networking.2015-07-16-18.03.html

Regards,
Daneyon Hansen
__
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] Would people see a value in the cve-check-tool?

[Clark, Robert Graham]

Hi Elena,

This is interesting work, thanks for posting it (and for posting it here on 
openstack-dev, we are trying to wind down the security ML) though maybe use the 
[Security] tag in the subject line next time.

I think this is a very interesting project, though it’s unclear to me who might 
be the targeted users for this? It seems like it would make the most sense for 
this to be in the gate. Now this could be the standard build gates (Jenkins 
etc) but I’m not sure how much sense that makes on its own, after all most 
production consumers (those who care about CVEs) of OpenStack are probably not 
consuming it vanilla from source but are more likely to be consuming it from a 
vendor who’s already packaged it up.

In the latter case, I’m sure vendors would find this tool very useful, we do 
something similar at HP today but I’m sure a tool like this would add value and 
it’s probably something we could contribute to.

As I write this I’ve realised that there would be an interesting possibility in 
the former case (putting this in the upstream OpenStack gates). It would be 
interesting to see something running that regularly checks for CVE’s in the 
libraries that _could_ be included in OpenStack, (library requirements within 
OpenStack often include more than one version) and bumps the version to the 
next safest and submits a change request for manual verification etc.

-Rob







From: Adam Heczko [mailto:ahec...@mirantis.com]
Sent: 03 August 2015 23:18
To: OpenStack Development Mailing List (not for usage questions)
Cc: Heath, Constanza M; Ding, Jian-feng; Demeter, Michael; Bhandaru, Malini K
Subject: Re: [openstack-dev] Would people see a value in the cve-check-tool?

Hi Elena, the tool looks very interesting.
Maybe try to spread out this proposal also through openstack-security@ ML.
BTW, I can't find the wrapper mentioned - am I missing something?

Regards,

Adam

On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena 
mailto:elena.reshet...@intel.com>> wrote:
Hi,

We would like to ask opinions if people find it valuable to include a 
cve-check-tool into the OpenStack continuous integration process?
A tool can be run against the package and module dependencies of OpenStack 
components and detect any CVEs (in future there are also plans to integrate 
more functionality to the tool, such as scanning of other vulnerability 
databases and etc.). It would not only provide fast detection of new 
vulnerabilities that are being released for existing dependencies, but also 
control that people are not introducing new vulnerable dependencies.

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

I am attaching an example of a very simple Python wrapper for the tool, which 
is able to process formats like: 
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
and an example of html output if you would be running it for the python module 
requests 2.2.1 version (which is vulnerable to 3 CVEs).

Best Regards,
Elena.



__
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



--
Adam Heczko
Security Engineer @ 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

Re: [openstack-dev] [neutron][qos][ml2] extensions swallow exceptions

[Abhishek Raut]

There is this review[1] trying to solve exactly what you¹re asking for.

I think it makes sense for the exceptions to be propagated all the way
back to the user instead of swallowing them and then roll back the
transaction. Does it even make sense to continue after a failure?

[1] https://review.openstack.org/#/c/202061/

‹Abhishek Raut

On 8/4/15, 3:02 AM, "Ihar Hrachyshka"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Hi all,
>
>in feature/qos, we use ml2 extension drivers to handle additional
>qos_policy_id field that can be provided thru API:
>
>http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
>/extensions/qos.py?h=feature/qos
>
>What we do in qos extension is we create a database 'binding' object
>between the updated port and the QoS policy that corresponds to
>qos_policy_id. So we access the database. It means there may be some
>complications there, f.e. the policy object is not available for the
>tenant, or just does not exist. In that case, we raise an exception
>from the extension, assuming that ml2 will propagate it to the user in
>some form.
>
>But it does not work. This is because _call_on_ext_drivers swallows
>exceptions:
>
>http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
>/managers.py#n766
>
>It makes me ask some questions:
>
>- - first, do we use extensions as was expected? Can we extend
>extensions to cover our use case?
>
>- - second, what would be the right way to go assuming we want to
>support the case? Should we just reraise? Or maybe postpone till all
>extension drivers are called, and then propagate an exception top into
>the stack? (Probably some extension manager specific exception?) Or
>maybe we want extensions to claim whether they may raise, and handle
>them accordingly?
>
>- - alternatively, if we abuse the API and should stop doing it, which
>other options do we have to achieve similar behaviour without relying
>on ml2 extensions AND without polluting ml2 driver with qos specific cod
>e?
>
>Thanks for your answers,
>Ihar
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz
>tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw
>BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF
>kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq
>HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV
>psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=
>=Fo++
>-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 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] [mistral] [yaql] Prepare to Yaql 1.0 release

[Dmitri Zimine]

This is great news Alex, was looking forward to it, will be happy to migrate 
Mistral. 

Some heads-up on what syntactically changed would be much appreciated to pass 
on to our users; 
we likely will catch much of them with Mistral tests, but some may bubble up. 

DZ. 

On Jul 27, 2015, at 2:04 AM, Alexander Tivelkov  wrote:

> Hi folks,
> 
> We are finally ready to release the 1.0.0 version of YAQL. It is a
> huge milestone: the language finally looks the way we initially wanted
> it to look. The engine got completely rewritten, tons of new
> capabilities have been added. Here is a brief (and incomplete) list of
> new features and improvements:
> 
> * Support for kwargs and keyword-only args (Py3)
> * Optional function arguments
> * Smart algorithm to find matching function overload without side effects
> * Ability to organize functions into layers
> * Configurable list of operators (left/right associative binary,
> prefix/suffix unary with precedence)
> * No global variables. There can be  more than one parser with
> different set of operators simultaneously
> * List literals ([a, b])
> * Dictionary literals ({ a => b})
> * Handling of escape characters in string literals
> * Verbatim strings (`...`) and double-quotes ("...")
> * =~ and !~ operators in default configuration (similar to Perl)
> * -> operator to pass context
> * Alternate operator names (for example '*equal' instead of '#operator_=')
>  so that it will be possible to have different symbol for particular operator
>  without breaking standard library that expects operator to have well
> known names
> * Set operations
> * Support for lists and dictionaries as a dictionary keys and set elements
> * New framework to decorate functions
> * Ability to distinguish between functions and methods
> * Switchable naming conventions
> * Unicode support
> * Execution options available to all invoked functions
> * Iterators limitation
> * Ability to limit memory consumption
> * Can work with custom context classes
> * It is possible to extend both parser and set of expression classes
> on user-side
> * It is possible to create user-defined types (also can be used for
> dependency injection)
> * Legacy yaql 0.2.x backward compatibility mode
> * Comprehensive standard library of functions
> * High unit test coverage
> * Delegate and lambda support, including higher order lambdas
> 
> etc, etc.
> 
> So, this is a big change.
> 
> And as it always happens when moving from 0.something to 1.x the
> breaking changes are inevitable. We have included the "backwards
> compatibility mode", but it may not address all the possible concerns.
> 
> So.
> We have released a release candidate 1 of yaql 1.0.0 on pypi: [1]
> It includes all the new functionality and is likely to be identical to
> final release (that's why it is RC after all) and we strongly
> encourage all the yaql users (Murano and Mistral first of all) to try
> it and prepare "migration patches" to use it. When the final release
> is out, we'll update the global requirements to yaql >= 1.0.0, which
> is likely to break all your gate checks unless you quickly land a
> migrating patch.
> 
> Please email us any concerns or contact me (ativelkov) or Stan Lagun
> (slagun) directly in IRC (#murano) if you need some quick help on yaql
> 1.0 or migrating from 0.2.x
> 
> Happy yaqling!
> 
> 
> [1] https://pypi.python.org/pypi/yaql/1.0.0.0rc1
> 
> 
> --
> Regards,
> Alexander Tivelkov
> 
> __
> 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] [mistral] BPMN support

[Dmitri Zimine]

Hi Noy, 

The short answer is No, BPMN is currently not supported, and No, we didn’t hear 
requests to support it yet. It is architecturally feasible but is a substantial 
effort, and not on the current roadmap. 

The longer answer is: Both Mistral DSL and BPMN come from the common root of 
workflow body of knowledge, The Workflow Reference Model. However specifics 
choices of 1) supported workflow patterns 2) syntax to express and 3) visual 
representations and 4) target users are all different, given the differences in 
the domain. Business processes are quite complex, and business users are much 
less technical, this forced more complexity into the workflow and workflow 
definition language - to express more visually and abstract it from “the code”. 

Industry experience with applying workflow to IT automation shown that few 
patterns are commonly used in the field. And technical IT users don’t hesitate 
dealing with the code (rather hesitate dealing with graphical tools or any 
tools that constraint them). 

Mistral DSL tried to strike the balance between using of workflow as a powerful 
abstraction, and keeping it simple, with minimal patterns to support typical IT 
operations. 

Mistral as workflow service is architecturally capable of supporting another 
workflow language; it’s a matter of writing workflow handler that supports  
BMPN syntax and implements underlying workflow logic.

Practically, however, BPMN may be too far away: it’s XML not YAML, it’s a 
different way to refer data, therefore an implementation may reviel more places 
were adjustments will be required. 

Hope this helps.

Cheers, 
Dmitri.


There’s no plans 
On Jul 23, 2015, at 1:05 AM, ITZIKOWITZ, Noy (Noy) 
 wrote:

> Hi,
> We had a question from our OSS team about the level of support of BPMN in 
> Mistral,
> Is there any plan to include that support? Did you heard from other people on 
> the community around the need for that?
> 
> Thanks,
> Noy
> __
> 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] [neutron][qos][ml2] extensions swallow exceptions

[Robert Kukura]

The process_[create|update]_() extension driver methods are 
intended to validate user input. Exceptions raised by these need to be 
returned to users so they know what they did wrong. These exceptions 
should not be logged as anything higher than info level, since user 
errors generally are not of concern to admins. Also, given that these 
methods are called within the create or update transaction, raising an 
exception will cause the entire transaction to be rolled back. Once an 
exceptions occurs in an extension driver, there is no point in 
continuing to call the other extension drivers since only one exception 
will be returned to the user at a time.


-Bob

On 8/4/15 2:26 PM, Abhishek Raut wrote:

There is this review[1] trying to solve exactly what you¹re asking for.

I think it makes sense for the exceptions to be propagated all the way
back to the user instead of swallowing them and then roll back the
transaction. Does it even make sense to continue after a failure?

[1] https://review.openstack.org/#/c/202061/

‹Abhishek Raut

On 8/4/15, 3:02 AM, "Ihar Hrachyshka"  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

in feature/qos, we use ml2 extension drivers to handle additional
qos_policy_id field that can be provided thru API:

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
/extensions/qos.py?h=feature/qos

What we do in qos extension is we create a database 'binding' object
between the updated port and the QoS policy that corresponds to
qos_policy_id. So we access the database. It means there may be some
complications there, f.e. the policy object is not available for the
tenant, or just does not exist. In that case, we raise an exception

>from the extension, assuming that ml2 will propagate it to the user in

some form.

But it does not work. This is because _call_on_ext_drivers swallows
exceptions:

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2
/managers.py#n766

It makes me ask some questions:

- - first, do we use extensions as was expected? Can we extend
extensions to cover our use case?

- - second, what would be the right way to go assuming we want to
support the case? Should we just reraise? Or maybe postpone till all
extension drivers are called, and then propagate an exception top into
the stack? (Probably some extension manager specific exception?) Or
maybe we want extensions to claim whether they may raise, and handle
them accordingly?

- - alternatively, if we abuse the API and should stop doing it, which
other options do we have to achieve similar behaviour without relying
on ml2 extensions AND without polluting ml2 driver with qos specific cod
e?

Thanks for your answers,
Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVwI29AAoJEC5aWaUY1u57yLYH/jhYmu4aR+ewZwSzDYXMcfdz
tD5BSYKD/YmDMIAYprmVCqOlk1jaioesFPMUOrsycpacZZWjg5tDSrpJ2Iz5/ZPw
BYLIPGaYF3Pu87LHrUKhIz4f2TfSWve/7GBCZ6AK6zVqCXky8A9MRfWrf774a8oF
kexP7qQVbyrOcXxZANDa1bJuLDsb4TiTcuuDizPtuUWlMfzmtZeauyieji/g1smq
HBO5h7zUFQ87YvBqq7ed2KhlRENxo26aSrpxTFkyyxJU9xH1J8q9W1gWO7Tw1uCV
psaijDmlxU/KySR97Ro8m5teu+7Pcb2cg/s57WaHWuAvPNW1CmfYc/XDn2I9KlI=
=Fo++
-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 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] [Ceilometer][AODH] Timeout Event Alarms

[gord chung]

hi Igor,

i would suggest you go with second option as i believe your 
implementation will overlap and reuse some of the functionality Ryota 
would code for his alarm spec [1]. also, since Aodh is working on an 
independent release cycle, it'll give you some more time as i don't 
think we'd be able to get this into Liberty if we went the pipeline route.


[1] 
http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html


On 04/08/2015 10:00 AM, Igor Degtiarov wrote:

Hi folks,

On our meatup we agreed to add timeout event alarms [1](Event-Base 
Alarming part).

In ToDo task "Сhoose the optimal way for timeout alerting implementation"
Now we have two proposition for implementation:
 - first is to add timeout param in event pipeline (transformer part) [2]
   -- weakness of this approach is that we cannot allow user change 
config files, so only administrator will be able to set rules for 
timeout events alarms, and that is not what we are expecting from alarms.
 - second is additional optional parameters in event alarms 
description like sequence of required events and timeout threshold. 
Event alarm evaluator looks thru getting events and evaluates alarm if 
even one event from required sequence isn't received in set "timeout".[3]


It seems that second approach is better it doesn't have restrictions 
for end user.

Hope for your help in choosing optimal way for implementation.
(In specs review there is silence now)

[1] 
https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle

[2] https://review.openstack.org/#/c/162167
[3] https://review.openstack.org/#/c/199005

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.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


--
--
gord

__
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] [Neutron][L3] Representing a networks connected by routers

[Carl Baldwin]

Kevin,

This is just a final top-post to say that I'm going to spend the next
week noodling over this discussion in more detail and trying to flesh
it out into a proposal.  I think we're pretty much in agreement about
where the problems are in the model.  It feels like we'll just be
beating a dead horse to continue to hash that out here.

I will take the action to write up a proposal based on this discussion
and have it posted before the 18th when we are planning to have a
discussion at the operators meetup.  I will focus on the L3 network
subnet group thingy, floating IPs, and how it relates to a group of L3
connected L2 segments.  I'll try to work out a migration plan both for
the DB and for existing work-loads.  I'll go back and review Assaf's
and others' comments on grouping the networks.  I will also consider
Neil's proposal for routed networks and how it fits in.  Maybe it fits
in better.

I will not focus much on the Nova scheduling aspect.  I acknowledge
that is an important aspect to solving this whole problem.  But, in my
mind, it hasn't changed much since we discussed it at the mid-cycle
and I think you had some interest in working it out.  Essentially,
there are still multiple segments modeled as neutron networks that
will be collected in to a group "somehow" and we have a way to pass
hints around like we discussed to schedule an instance and create a
port on the appropriate network.

Carl

__
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] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

[Kevin Benton]

I will be in China that week for the bug hackathon. I will be happy to dial
in though assuming it's a reasonable time (e.g. morning PST).

On Tue, Aug 4, 2015 at 10:39 AM, Kyle Mestery  wrote:

> Google Hangout should work fine! And Carl and I will both be at Linuxcon
> and together, so we can dial in together. This time should work for us, so
> thanks for taking us into consideration Mike!
>
> Kyle
>
> On Tue, Aug 4, 2015 at 9:29 AM, Mike Dorman  wrote:
>
>> Ok, cool.  We plan to discuss this during the LDT time slot at 1330-1500
>> Pacific on Tuesday 8/18.  We can have this as the first agenda item so
>> there’s a defined start time for those who are remote.
>>
>> I'll take ownership of setting up a hangout (or whatever.)  Do people
>> have a preference on what videoconference tool to us?  Absent any opinions,
>> I’ll just do a Google Hangout.
>>
>> Thanks!
>> Mike
>>
>>
>> From: Kyle Mestery
>> Date: Tuesday, August 4, 2015 at 8:09 AM
>> To: Ryan Moats
>> Cc: Mike Dorman, "OpenStack Development Mailing List (not for usage
>> questions)", OpenStack Operators
>>
>> Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3] [Large
>> Deployments Team] Representing a networks connected by routers
>>
>> Can you also try to have some sort of remote option? I'd like to attend
>> this, and I'd like Carl to try and attend as well. Thanks!
>>
>> On Tue, Aug 4, 2015 at 8:50 AM, Ryan Moats  wrote:
>>
>>> I will be there for my lightning talk, and I think armax and
>>> kevin_benton will be there - it would be good to find some time for us to
>>> pow-wow, along with some teleconference so that carl_baldwin and mestery
>>> can join in...
>>>
>>> Ryan Moats (regXboi)
>>>
>>> Mike Dorman  wrote on 08/03/2015 10:07:23 PM:
>>>
>>> > From: Mike Dorman 
>>> > To: "OpenStack Development Mailing List (not for usage questions)"
>>> > , OpenStack Operators >> > operat...@lists.openstack.org>
>>> > Date: 08/03/2015 10:08 PM
>>> > Subject: Re: [Openstack-operators] [openstack-dev] [Neutron][L3]
>>> > [Large Deployments Team] Representing a networks connected by routers
>>>
>>> >
>>> > I hope we can move this idea moving forward.  I was disappointed to
>>> see
>>> > the spec abandoned.
>>> >
>>> > Some of us from the large deployers group will be at the Ops Meetup.
>>> Will
>>> > there be any representation from Neutron there that we could discuss
>>> with
>>> > more?
>>> >
>>> > Thanks,
>>> > Mike
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 8/3/15, 12:27 PM, "Carl Baldwin"  wrote:
>>> >
>>> > >Kevin, sorry for the delay in response.  Keeping up on this thread was
>>> > >getting difficult while on vacation.
>>> > >
>>> > >tl;dr:  I think it is worth it to talk through the idea of inserting
>>> > >some sort of a "subnet group thing" in the model to which floating ips
>>> > >(and router external gateways) will associate.  It has been on my mind
>>> > >for a long time now.  I didn't pursue it because a few informal
>>> > >attempts to discuss it with others indicated to me that it would be a
>>> > >difficult heavy-lifting job that others may not appreciate or
>>> > >understand.  Scroll to the bottom of this message for a little more on
>>> > >this.
>>> > >
>>> > >Carl
>>> > >
>>> > >On Tue, Jul 28, 2015 at 1:15 AM, Kevin Benton 
>>> wrote:
>>> > >>>Also, in my proposal, it is more the router that is the grouping
>>> > >>>mechanism.
>>> > >>
>>> > >> I can't reconcile this with all of the points you make in the rest
>>> of
>>> > >>your
>>> > >> email. You want the collection of subnets that a network
>>> represents,
>>> > >>but you
>>> > >> don't want any other properties of the network.
>>> > >
>>> > >This is closer to what I'm trying to say but isn't quite there.  There
>>> > >are some subnets that should be associated with the segments
>>> > >themselves and there are some that should be associated with the
>>> > >collection of segments.  I want floating IPs that are not tied the an
>>> > >L2 network.  None of the alternate proposals that I'd heard addressed
>>> > >this.
>>> > >
>>> > >>>that the network object is currently the closest thing we have to
>>> > >>> representing the L3 part of the network.
>>> > >>
>>> > >> The L3 part of a network is the subnets. You can't have IP
>>> addresses
>>> > >>without
>>> > >> the subnets, you can't have floating IPs without the subnets, etc.
>>> > >
>>> > >You're right but in the current model you can't have IP addresses
>>> > >without the network either which is actually the point I'm trying to
>>> > >make.
>>> > >
>>> > >> A Neutron network is an L2 construct that encapsulates L3 things. By
>>> > >> encapsulating them it also provides an implicit grouping. The routed
>>> > >> networks proposal basically wants that implicit grouping without the
>>> > >> encapsulation or the L2 part.
>>> > >
>>> > >This sounds about right.  I think it is wrong to assume that we need
>>> > >an L2 network to encapsulate L3 things.  I'm feeling restricted by the
>>> > >model and the insistence that a neutron net

Re: [openstack-dev] [nova] Thoughts on things that don't make freeze cutoffs

[Matt Riedemann]

On 8/4/2015 8:47 AM, Sahid Orentino Ferdjaoui wrote:

On Tue, Aug 04, 2015 at 12:54:34PM +0200, Thierry Carrez wrote:

John Garbutt wrote:

[...]
Personally I find a mix of coding and reviewing good to keep a decent
level of empathy and sanity. I don't have time for any coding this
release (only a bit of documenting), and its not something I can
honestly recommend as a best practice. If people don't maintain a good
level of reviews, we do tend to drop those folks from nova-core.

I know ttx has been pushing for dedicated reviewers. It would be nice
to find folks that can do that, but we just haven't found any of those
people to date.


Hell no! I'd hate dedicated reviewers.

[...]
This is why I advocate dividing code / reviewers / expertise along
smaller areas within Nova, so that new people can focus and become a
master again. What I'm pushing for is creating Nova subteams with their
own core reviewers, which would be experts and trusted to +2 on a
defined subset of code.


Yep this makes a lot of sense and unfortunately we bring this idea
every time but nothing seems to move in that way.

Contributors working in Nova feel more and more frustrated.

So specs got approved June 23-25 then about 15 working days to push
all of the code and 12 working days to make it merged. From my
experience working on Nova it's not possible. For instance on libvirt
driver we have one core who does most of the reviews, but we have
problem to find the +2/+W and without to mention problem when he
is author of the fix [1].

We delay good features (with code pushed and waiting reviews) we can
bring to users. I guess users are happy to hear that we are working
hard to improve our code base but perhaps they also want features
without to wait a year (3.1, 95, 98, me, xp...).

And I know that because I'm working every days in Nova since more than
2 years - We have really skilled people who can help.

[1] https://review.openstack.org/#/c/176360/

s.

__
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



Yeah so this thread is starting to devolve into scaling the core team 
again, which is what I didn't want to happen.  The goal was to talk 
about how we can line up things in a backlog to still allow review and 
possible inclusion to a release after the spec freeze cutoff, but not 
necessarily target something for inclusion (like that rbd snapshot 
example), and not detract from what has been approved before the spec 
freeze cutoff or other priorities.


I think I got the answer from John which is the path forward is starting 
to kick the tires on some new tooling like phabricator and then doing 
some things with runways / kanban boards so we don't have as rigid a 
process, we just queue up things as they come.


So I'm satisfied for now.

--

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] Would people see a value in the cve-check-tool?

[Jeremy Stanley]

On 2015-08-04 18:17:13 + (+), Clark, Robert Graham wrote:
[...]
> As I write this I’ve realised that there would be an interesting
> possibility in the former case (putting this in the upstream
> OpenStack gates). It would be interesting to see something running
> that regularly checks for CVE’s in the libraries that _could_ be
> included in OpenStack, (library requirements within OpenStack
> often include more than one version) and bumps the version to the
> next safest and submits a change request for manual verification
> etc.

On a separate (private) E-mail thread where I recommended restarting
this discussion here in public, that was more or less the intent. We
have a mechanism for the openstack/requirements repo presently which
resolves the current highest versions of all dependencies (including
all their transitive dependencies) declared in the
global-requirements.txt file and updates a file called
upper-constraints.txt with the result. The proposed check tool
could, in theory, consume this upper-constraints.txt and so run and
report periodically on the state of package versions declared in
that file.

To take things a step further, when someone proposes a change to
global-requirements.txt, a check job could generate the new
upper-constraints.txt which would result from that and feed it into
this CVE tool, reporting back on whether that proposed change would
bring in any known-vulnerable versions of packages. This would most
likely operate only in an advisory fashion, providing information to
reviewers of requirements changes and any other interested parties,
since I can envision circumstances under which its results would
need to be temporarily ignored/overridden.

All that is to say, I think the infrastructure integration for this
is pretty straightforward. What I'd rather see first is people
trying out the tool, finding out what it tells us about the present
state of our requirements list, whether it's reliable or needs
further work, whether its featureset is already sufficient, et
cetera.
-- 
Jeremy Stanley


signature.asc
Description: 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] Would people see a value in the cve-check-tool?

[Ian Cordasco]

On 8/4/15, 13:17, "Clark, Robert Graham"  wrote:

>Hi Elena,
> 
>This is interesting work, thanks for posting it (and for posting it here
>on openstack-dev, we are trying to wind down the security
> ML) though maybe use the [Security] tag in the subject line next time.
> 
>I think this is a very interesting project, though it’s unclear to me who
>might be the targeted users for this? It seems like it
> would make the most sense for this to be in the gate. Now this could be
>the standard build gates (Jenkins etc) but I’m not sure how much sense
>that makes on its own, after all most production consumers (those who
>care about CVEs) of OpenStack are probably
> not consuming it vanilla from source but are more likely to be consuming
>it from a vendor who’s already packaged it up.
> 
>In the latter case, I’m sure vendors would find this tool very useful, we
>do something similar at HP today but I’m sure a tool like
> this would add value and it’s probably something we could contribute to.
> 
>As I write this I’ve realised that there would be an interesting
>possibility in the former case (putting this in the upstream OpenStack
> gates). It would be interesting to see something running that regularly
>checks for CVE’s in the libraries that _could_ be included in OpenStack,
>(library requirements within OpenStack often include more than one
>version) and bumps the version to the
> next safest and submits a change request for manual verification etc.
> 
>-Rob

Since requests was already brought up in the discussion below and we're
discussing potential uses for this in the gate, let me throw in my two
cents as a requests core developer. The mere presence of a CVE id for a
release does not in anyway imply an effect on OpenStack. In the CVEs in
question (which Elena referred to) we have three separate issues:

1. Authentication credentials being sent on redirect to the wrong domain,
e.g., attempt to authenticate to example.com which redirects to
example.org and we would faithfully continue to attempt to authenticate.

2. See 1 but for proxies

3. Cookies sent with a redirect to a different domain were set for the
domain we were redirected to instead of the domain we were redirected from.

When I tried bumping the version for the first two, we had a discussion
about the impact to OpenStack and it was decided that there wasn't a
necessity to bump the version. There was no need to have a discussion
about 3 because (as far as I'm aware) there isn't any service that uses
cookies so that also doesn't have any effect.

Being aware of these CVEs is one thing and would be nice. If we can
determine that a CVE affects us, we most certainly should bump the minimum
required version of that library in OpenStack. That said, part of the
argument against increasing the lower bound on requests (at the time) was
due to packagers not wanting to or being able to (I forget which) package
the newer version (and no the review was not sent to a stable/* branch).
So if we're going to be conflicting with downstream re-distributors, then
this might be harder than we think.

I have to agree that this is something that some Vendors will find useful.
I suspect stackforge/os-ansible-deployment and stackforge/kolla will both
find this useful as they both build OpenStack from source (although for
the  latter it is an option rather than a requirement). For Vendors
depending distro packaged OpenStack (MOS if I remember correctly uses
Debian's OpenStack packages), this will be of no interest and may be a
waste of time. For example, Debian and Ubuntu should both be packaging
python-requests-2.2.1 (this in fact is a reason why we had gate failures
when urllib3 1.11 was released) but it should absolutely be patched for
all three CVEs (making it not exactly 2.2.1 but that's besides the point).
Those vendors should be trusting their curated packages to be properly
patched for them.

__
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] [nova] Proposal for an Experiment

[Roman Vasilets]

Rally? Something else? What can we do to measure this?
Of cause, if you looking for instrument for measure performance - Rally is
the best choice!

On Tue, Aug 4, 2015 at 5:38 PM, Ed Leafe  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 08/03/2015 02:24 PM, Jesse Cook wrote:
>
> > Performance tests against 1000 node clusters being setup by OSIC?
> > Sounds like you have a playground for your tests.
>
> Unfortunately, the consensus of the nova cores during the mid-cycle
> meetup was that while this is an interesting approach, and that
> experimenting with novel approaches can be very worthwhile, it was not
> considered a priority, as there is too much work already on everyone's
> plate for Liberty. So the experiment isn't going to happen any time soon
> .
>
> - --
>
> - -- Ed Leafe
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIbBAEBCgAGBQJVwM5gAAoJEKMgtcocwZqLG90P9RNKm4pRmcLPK+PqVaXCIu/E
> c+i0SW9Af5fmy4cC7Efnuv2o7UqJNNU7GsGw3on54Lt1SoF3z1yJ/9WarzjiNLq+
> 25Uz+2HDytovvnREi+P/LoVB4mj49nowEkMh/3QgQWVsMOvPitPM7mBPAGkyzNvb
> 5ElC1Xr2HkyQ/9h34IGLWcC/X/meR79BcvRHfJwqzNyTP2foi7tboq4sugbFVQfy
> 72vbaTAtLI/mDzUjkafNGB5W2ge4VWAJRsjf1y+eIv+j2f3PKbKsx3XLrTIuzJ78
> 9qBmpGal/biqyUwFyrvrg/e//KuD0FhJdiDwiuc35hebkN7UBJbq71RAjdxtK4Jr
> clImy04sGAvKI0r27LFZA3ycjv0J8OW4nJeH9vjdBg5N2D0FuhOIBNxXsKohdF42
> 0maWFe1Wj7Icv9YnJ26ZaaWjqwnGE/PjVl3lFd1X5W7KFJ5Ay/uYY28cfHbD0wKT
> Ych2oSR0/Jrzzfm9jd+VP2kjORgtEdDaARbP11auT+o1xnIKLIA9qTiOGuhX807L
> cZVitPoUdIlogQyKJ6hZtiIytrnnYocHKZp/MQjpTabVKkl4aKmKLAo2onNgDcD8
> 6B08hmsW28pm7aKZf0SBb7oe6OU0vCQjFaKWAVb1O+zGqspOrhqehQR3u6nF+O1Y
> TaG3j4n4w/5D9gadk4k=
> =l9oR
> -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 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] Would people see a value in the cve-check-tool?

[Jeremy Stanley]

On 2015-08-04 20:37:37 + (+), Ian Cordasco wrote:
[...]
> When I tried bumping the version for the first two, we had a discussion
> about the impact to OpenStack and it was decided that there wasn't a
> necessity to bump the version. There was no need to have a discussion
> about 3 because (as far as I'm aware) there isn't any service that uses
> cookies so that also doesn't have any effect.
> 
> Being aware of these CVEs is one thing and would be nice. If we can
> determine that a CVE affects us, we most certainly should bump the minimum
> required version of that library in OpenStack. That said, part of the
> argument against increasing the lower bound on requests (at the time) was
> due to packagers not wanting to or being able to (I forget which) package
> the newer version (and no the review was not sent to a stable/* branch).
> So if we're going to be conflicting with downstream re-distributors, then
> this might be harder than we think.
[...]

I don't think the intent of this is to blacklist potentially
vulnerable versions of dependencies, it's to help us not prevent the
use of fixed versions. Evaluating our upper-constraints.txt would in
theory let us know:

1. dependencies which have been basically abandoned by their
   caretakers and have fallen into a vulnerable state, so
   potentially need assistance from our community

2. dependencies on which we have a restrictive upper bound, which
   prevents our users from consuming a release where some
   vulnerability has been fixed

Arguably also 3. lots of CVEs which aren't applicable for some
reason, so we likely need a means to whitelist those and filter them
from the report.
-- 
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