[openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay

[Jay Lau]

Hi Magnum,

The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a DCOS
which focus on container service based on mesos.

For more detail, please refer to
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/

The mesosphere now has a template on AWS which can help customer deploy a
DCOS on AWS, it would be great if Magnum can also support it based on
OpenStack.

I filed a bp here https://blueprints.launchpad.net/magnum/+spec/mesos-dcos
, please show your comments if any.
-- 
Thanks,

Jay Lau (Guangya Liu)
__
OpenStack Development Mailing 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] Enhance Mesos bay to a DCOS bay

[Guz Egor]

Jay, I think we should check license first. I believe DCOS is commercial 
product from Mesosphere. And you can use community version at AWS for free,but 
only because Mesosphere allows it and there is no source code.
--- Egor
  From: Jay Lau 
 To: OpenStack Development Mailing List  
 Sent: Thursday, March 24, 2016 11:57 PM
 Subject: [openstack-dev] [magnum] Enhance Mesos bay to a DCOS bay
   
Hi Magnum,The current mesos bay only include mesos and marathon, it is better 
to enhance the mesos bay have more components and finally enhance it to a DCOS 
which focus on container service based on mesos.For more detail, please refer 
to 
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/The
 mesosphere now has a template on AWS which can help customer deploy a DCOS on 
AWS, it would be great if Magnum can also support it based on OpenStack.I filed 
a bp here https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please 
show your comments if any.
-- 
Thanks,

Jay Lau (Guangya Liu)

__
OpenStack Development Mailing 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] Where the FU(EL) did my puppet files go?

[Bogdan Dobrelya]

On 03/25/2016 12:08 AM, Andrew Woodward wrote:
> With the merging of last bits of changes of fuel-openstack-tasks[1],
> fuel-remove-conflict-openstack, and
> fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3] a lot of
> the files structure relating to tasks has changed in fuel-library.
> 
> [1] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
> [2]
> https://blueprints.launchpad.net/fuel/+spec/fuel-remove-conflict-openstack
> [3]
> https://blueprints.launchpad.net/fuel/+spec/fuel-refactor-osnailyfacter-for-puppet-master-compatibility
> 
> With fuel-remove-conflict-openstack:
> 
> You will now see that we are heavy into removing the ::openstack::
> module from fuel-library, manifests logic that was here has been
> refactored into the task. Some stubs where left and you should expect
> more cleanup and removal in Newton
> 
> With fuel-refactor-osnailyfacter-for-puppet-master-compatibility:
> 
> We now have separated the task entry point from the most of the puppet
> in the task. Given any task the entry point is an include stub, while
> the meaty puppet is in a corresponding class.
> 
> if we had an example task:
> 
>   osnailyfacter/moduler/globals/globals.pp
> 
> the guts will have moved to:
> 
>   osnailyfacter/manifests/globals/globals.pp
> 
> and will live in a class
> 
>   class osnailyfacter::globals::globals {
> 
>   }
> 
> and the task entry 'osnailyfacter/moduler/globals/globals.pp' will contain
> 
>   include ::osnailyfacter::globals::globals
> 
> And finally, with fuel-openstack-tasks:
> 
> We have moved task definitions (tasks.yaml), entry-points, manifests,
> etc... related to installing openstack from osnailyfacter to
> openstack_tasks. This also includes the Puppetfile definitions for
> puppet-openstack modules. They will remain in fuel-library module in

We missed impact to the noop tests coverage [0]
Let's please address missing noop tests and tasks ASAP

[0] https://bugs.launchpad.net/fuel/+bug/1561890

> Mitaka, and will most likely become their own module in Newton. In
> addtion to them being moved, we have also left stubs for the old entry
> points (updated to the new include location) in osnailyfacter, they will
> be removed in Newton.
> 
> for example:
> 
>   osnailyfacter/manifests/roles/*
>   osnailyfacter/modular/roles/*
> 
> moved to:
> 
>   openstack_tasks/manifests/roles/*
>   openstack_tasks/examples/roles/*
> 
> -- 
> 
> --
> 
> Andrew Woodward
> 
> Mirantis
> 
> Fuel Community Ambassador
> 
> Ceph Community
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] [kite] Seeking core reviewers

[Thierry Carrez]

Ian Cordasco wrote:

I believe Kite is no longer actively developed or maintained and was started by 
the Barbican folks. You should find them in #openstack-barbican.


Yeah. It's still technically a repository under the Barbican team. 
Someone from Barbican should propose a governance change to get rid of 
it (or approve someone else's change getting rid of it).


Keeping abandoned repositories in your official list does not reflect 
well on your project team (or OpenStack in general).


--
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] [magnum] Enhance Mesos bay to a DCOS bay

[Michal Rostecki]

On 03/25/2016 07:57 AM, Jay Lau wrote:

Hi Magnum,

The current mesos bay only include mesos and marathon, it is better to
enhance the mesos bay have more components and finally enhance it to a
DCOS which focus on container service based on mesos.

For more detail, please refer to
https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/

The mesosphere now has a template on AWS which can help customer deploy
a DCOS on AWS, it would be great if Magnum can also support it based on
OpenStack.

I filed a bp here
https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please show
your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)



Sorry if I'm missing something, but isn't DCOS a closed source software?

However, the "DCOS cli"[1] seems to be working perfectly with Marathon 
and Mesos installed by any way if you configure it well. I think that 
the thing which can be done in Magnum is to make the experience with 
"DOCS" tools as easy as possible by using open source components from 
Mesosphere.


Cheers,
Michal

[1] https://github.com/mesosphere/dcos-cli

__
OpenStack Development Mailing 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] NUMA + SR-IOV

[Sergey Nikitin]

Guys, thank you for fast response. I'm glad that I'm not a single one who
face this problem.

2016-03-24 19:54 GMT+03:00 Czesnowicz, Przemyslaw <
przemyslaw.czesnow...@intel.com>:

>
>
> > -Original Message-
> > From: Nikola Đipanov [mailto:ndipa...@redhat.com]
> > Sent: Thursday, March 24, 2016 4:34 PM
> > To: Sergey Nikitin ; OpenStack Development
> Mailing
> > List (not for usage questions) 
> > Cc: Czesnowicz, Przemyslaw 
> > Subject: Re: [openstack-dev] [nova] NUMA + SR-IOV
> >
> > On 03/24/2016 04:18 PM, Sergey Nikitin wrote:
> > >
> > > Hi, folks.
> > >
> > > I want to start a discussion about NUMA + SR-IOV environment. I have a
> > > two-sockets server. It has two NUMA nodes and only one SR-IOV PCI
> > > device. This device is associated with the first NUMA node. I booted a
> > > set of VMs with SR-IOV support. Each of these VMs was booted on the
> > > first NUMA node. As I understand it happened for better performance
> > > (VM should be booted in NUMA node which has PCI device for this VM)
> > [1].
> > >
> > > But this behavior leaves my 2-sockets machines half-populated. What if
> > > I don't care about SR-IOV performance? I just want every VM from *any*
> > > of NUMA nodes to use this single SR-IOV PCI device.
> > >
> > > But I can't do it because of behavior of numa_topology_filter. In this
> > > filter we want to know if current host has required PCI device [2].
> > > But we want to have this device *only* in some numa cell on this host.
> > > It is hardcoded here [3]. If we do *not* pass variable "cells" to the
> > > method
> > > support_requests() [4] we will boot VM on the current host, if it has
> > > required PCI device *on host* (maybe not in the same NUMA node).
> > >
> > > So my question is:
> > > Is it correct that we *always* want to boot VM in NUMA node associated
> > > with requested PCI device and user has no choice?
> > > Or should we give a choice to the user and let him boot a VM with PCI
> > > device, associated with another NUMA node?
> > >
>
> The rationale for choosing this behavior was that if you are requiring a
> NUMA topology for your VM
> and you request an SRIOV device as well then this is an high performance
> application and it should be configured appropriately.
>
> Similarly if you request hugepages your VM will be confined to one NUMA
> (unless specified otherwise)
> node and if there is no single NUMA node with enough resources it won't be
> created.
>
>
> >
> > This has come up before, and the fact that it keeps coming up tells me
> that
> > we should probably do something about it.
> >
> > Potentially it makes sense to be lax by default unless user specifies
> that they
> > want to make sure that the device is on the same NUMA node, but that is
> > not backwards compatible.
> >
> > It does not make sense to ask user to specify that they don't care IMHO,
> as
> > unless you know there is a problem (and users have nowhere near enough
> > information to tell), there is no reason for you to specify it - it's
> just not
> > sensible UI IMHO.
> >
>
> Yes this did come up few times, having a way to specify a requirement is
> probably a good idea.
> If it would be done the way you propose that would change the behavior for
> existing users, not sure how big problem this is.
>
> Przemek
>
> > My 0.02 cents.
>
>
>
>
>
> >
> > N.
> >
> > >
> > > [1]
> > > https://specs.openstack.org/openstack/nova-
> > specs/specs/kilo/implemente
> > > d/input-output-based-numa-scheduling.html
> > > [2]
> > >
> > https://github.com/openstack/nova/blob/master/nova/scheduler/filters/n
> > > uma_topology_filter.py#L85
> > > [3]
> > >
> > https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L
> > 1
> > > 246-L1247 [4]
> > > https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L277
>
>
__
OpenStack Development Mailing 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] Nominating Julia Kreger for core reviewer

[Vladyslav Drok]

+1!

On Fri, Mar 25, 2016 at 4:03 AM, Zhenguo Niu  wrote:

> +1, thanks for all the hard work Julia!
>
> On Fri, Mar 25, 2016 at 8:39 AM, 守屋哲 / MORIYA，SATORU <
> satoru.moriya...@hitachi.com> wrote:
>
>> +1 for me. She has given lots of valuable reviews to boot from volume
>> effort.
>> Thanks Julia!
>>
>> Satoru
>>
>> > -Original Message-
>> > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
>> > Sent: Friday, March 25, 2016 4:09 AM
>> > To: openstack-dev@lists.openstack.org
>> > Subject: [!][openstack-dev] [ironic] Nominating Julia Kreger for core
>> reviewer
>> >
>> > Hey all,
>> >
>> > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
>> > the Bifrost project, gives super valuable reviews, is beginning to lead
>> > the boot from volume efforts, and is clearly an expert in this space.
>> >
>> > All in favor say +1 :)
>> >
>> > // jim
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> OpenStack Development Mailing 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] NUMA + SR-IOV

[Sergey Nikitin]

FYI: I created blueprint
https://blueprints.launchpad.net/nova/+spec/share-pci-device-between-numa-nodes
and want to discuss it in Austin.

2016-03-25 9:49 GMT+03:00 Sergey Nikitin :

> Guys, thank you for fast response. I'm glad that I'm not a single one who
> face this problem.
>
> 2016-03-24 19:54 GMT+03:00 Czesnowicz, Przemyslaw <
> przemyslaw.czesnow...@intel.com>:
>
>>
>>
>> > -Original Message-
>> > From: Nikola Đipanov [mailto:ndipa...@redhat.com]
>> > Sent: Thursday, March 24, 2016 4:34 PM
>> > To: Sergey Nikitin ; OpenStack Development
>> Mailing
>> > List (not for usage questions) 
>> > Cc: Czesnowicz, Przemyslaw 
>> > Subject: Re: [openstack-dev] [nova] NUMA + SR-IOV
>> >
>> > On 03/24/2016 04:18 PM, Sergey Nikitin wrote:
>> > >
>> > > Hi, folks.
>> > >
>> > > I want to start a discussion about NUMA + SR-IOV environment. I have a
>> > > two-sockets server. It has two NUMA nodes and only one SR-IOV PCI
>> > > device. This device is associated with the first NUMA node. I booted a
>> > > set of VMs with SR-IOV support. Each of these VMs was booted on the
>> > > first NUMA node. As I understand it happened for better performance
>> > > (VM should be booted in NUMA node which has PCI device for this VM)
>> > [1].
>> > >
>> > > But this behavior leaves my 2-sockets machines half-populated. What if
>> > > I don't care about SR-IOV performance? I just want every VM from *any*
>> > > of NUMA nodes to use this single SR-IOV PCI device.
>> > >
>> > > But I can't do it because of behavior of numa_topology_filter. In this
>> > > filter we want to know if current host has required PCI device [2].
>> > > But we want to have this device *only* in some numa cell on this host.
>> > > It is hardcoded here [3]. If we do *not* pass variable "cells" to the
>> > > method
>> > > support_requests() [4] we will boot VM on the current host, if it has
>> > > required PCI device *on host* (maybe not in the same NUMA node).
>> > >
>> > > So my question is:
>> > > Is it correct that we *always* want to boot VM in NUMA node associated
>> > > with requested PCI device and user has no choice?
>> > > Or should we give a choice to the user and let him boot a VM with PCI
>> > > device, associated with another NUMA node?
>> > >
>>
>> The rationale for choosing this behavior was that if you are requiring a
>> NUMA topology for your VM
>> and you request an SRIOV device as well then this is an high performance
>> application and it should be configured appropriately.
>>
>> Similarly if you request hugepages your VM will be confined to one NUMA
>> (unless specified otherwise)
>> node and if there is no single NUMA node with enough resources it won't
>> be created.
>>
>>
>> >
>> > This has come up before, and the fact that it keeps coming up tells me
>> that
>> > we should probably do something about it.
>> >
>> > Potentially it makes sense to be lax by default unless user specifies
>> that they
>> > want to make sure that the device is on the same NUMA node, but that is
>> > not backwards compatible.
>> >
>> > It does not make sense to ask user to specify that they don't care
>> IMHO, as
>> > unless you know there is a problem (and users have nowhere near enough
>> > information to tell), there is no reason for you to specify it - it's
>> just not
>> > sensible UI IMHO.
>> >
>>
>> Yes this did come up few times, having a way to specify a requirement is
>> probably a good idea.
>> If it would be done the way you propose that would change the behavior
>> for existing users, not sure how big problem this is.
>>
>> Przemek
>>
>> > My 0.02 cents.
>>
>>
>>
>>
>>
>> >
>> > N.
>> >
>> > >
>> > > [1]
>> > > https://specs.openstack.org/openstack/nova-
>> > specs/specs/kilo/implemente
>> > > d/input-output-based-numa-scheduling.html
>> > > [2]
>> > >
>> > https://github.com/openstack/nova/blob/master/nova/scheduler/filters/n
>> > > uma_topology_filter.py#L85
>> > > [3]
>> > >
>> > https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L
>> > 1
>> > > 246-L1247 [4]
>> > > https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L277
>>
>>
>
__
OpenStack Development Mailing 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] Nominating Julia Kreger for core reviewer

[Ruby Loo]

On 24 March 2016 at 15:08, Jim Rollenhagen  wrote:

> Hey all,
>
> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> the Bifrost project, gives super valuable reviews, is beginning to lead
> the boot from volume efforts, and is clearly an expert in this space.
>
> All in favor say +1 :)
>
> // jim
>
>
+1! Great idea. :D

--ruby
__
OpenStack Development Mailing 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] Nominating Julia Kreger for core reviewer

[Dmitry Tantsur]

24 марта 2016 г. 8:12 PM пользователь "Jim Rollenhagen" <
j...@jimrollenhagen.com> написал:
>
> Hey all,
>
> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> the Bifrost project, gives super valuable reviews, is beginning to lead
> the boot from volume efforts, and is clearly an expert in this space.
>
> All in favor say +1 :)

+1

>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Jeremy Stanley]

On 2016-03-25 08:41:51 -0400 (-0400), Doug Hellmann wrote:
> All of our projects are able to tag releases in master *and* stable
> branches. We regularly release stable updates to libraries.
> 
> I'm embarrassed to say I don't know what the job you describe about
> merging tags into master does. If the commit that was tagged on a stable
> branch doesn't exist in master, what gets the tag in master? Or is the
> stable branch commit merged back into master?

It was invented as a workaround for this problem:

1. Create a new stable branch during the RC period.
2. Tag the first release on the new stable branch.
3. Compare dev versioning between new stable branch and master,
   you'll see that master's version is lower because it contains
   no record there's been a release tagged yet.

If the tag on the stable branch is higher than the tag on master, we
merge the tag and its history into master but keep the current
master branch state via this script:

http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/merge_tags.sh

It's possible that the logic there requires revisiting due to
nuanced changes in our release model, but it should still be
generally applicable.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Roman Prykhodchenko]

+1

> 25 бер. 2016 р. о 13:31 Dmitry Pyzhov  написав(ла):
> 
> As we are going to deprecate logs on UI I'm going to mark following bugs as 
> "won't fix". Any objections?
> High priority bug:
> https://bugs.launchpad.net/fuel/+bug/1553170 
> 
> Medium priority:
> https://bugs.launchpad.net/fuel/+bug/1554546 
> 
> https://bugs.launchpad.net/fuel/+bug/1539508 
> 
> 
> On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko  > wrote:
> Folks, I’ve registered a blueprint [1] and created an etherpad document [2] 
> where we can co-work on the spec before posting it to a formal review. Let’s 
> cooperate to summarize what we need to do.
> 
> 
> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun 
> 
> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun 
> 
> 
> - romcheg
> 
> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya  > > написав(ла):
> >
> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
> >> +1 to Vitaliy, it would be nice find somewhere a details for migration.
> >> And one more concern I should highlight - for some users logless UI may
> >> be challenging thing.
> >> The logs removing shouldn't affect the UX.
> >
> > Logs will still live at the master node's /var/log/remote
> >
> >>
> >>
> >> Nastya.
> >>
> >>
> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward  >> 
> >> >> wrote:
> >>
> >>I think we can address it by retaining deployment logs in
> >>nailgun/ui, this also removes the chicken and egg problem. after LMA
> >>is deployed it can be allowed to re-own 'logs' button on UI once
> >>it's deployed, including redirecting fuel logs there.
> >>
> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
> >> 
> >> >> wrote:
> >>
> >>We can sort out details later. In a worst case, the warning will
> >>be there in Newton too, and feature will go away only in O*
> >>release. So let's proceed with the bug..
> >>
> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
> >> 
> >> >> wrote:
> >>
> >>We can add the warning, but I think before we do this we
> >>should have clear migration plan. According to this thread,
> >>some parts are still not clear.
> >>
> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
> >> 
> >> >>:
> >>
> >>Deprecation warning for Fuel
> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244 
> >> .
> >>
> >>
> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
> >> 
> >> >> wrote:
> >>
> >>Since there are a lot of supporters for this idea,
> >>what do you folks think about creating a BP spec
> >>where we can describe what we should do in order to
> >>remove logs from UI and Nailgun? I also propose to
> >>file a bug about adding a deprecation warning to
> >>Mitaka release of Fuel.
> >>
> >>
> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
> >>>
> >>> >>> >> написав(ла):
> >>>
> >>>On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
> +1 to remove logs from Fuel UI in Fuel Newton.
> In Fuel Mitaka we'd need to put a deprecation
> warning somewhere.
> >>>
> >>>I agree, there is not much sense having non
> >>>flexible (no content
> >>>filters) logs view in UI. LMA plugins shall cover
> >>>this area as well.
> >>>
> 
> 
> On Fri, Mar 11, 2016, 04:57 Patrick Petit
>  
>  >
> 

[openstack-dev] [neutron] NaaS using Openstack Neutron

[Manuel Fernandes]

Hello to all,

My name is Manuel, I'm a MsC student in Computing and Telematics engineering at 
the University of Aveiro in Portugal and I'm currently working on my MsC 
thesis, which the topic is "Network as a Service (NaaS) using Openstack - 
Neutron". My main goal is to get a way to extend the virtual networks created 
in Openstack to the network outside of the datacenter (for example a campus 
network) to get external devices on the same L2 domain as the VMs on the 
virtual network, now this scenario is possible using the extension "Provider 
Network", but the external network operator needs to configure all the devices 
manually one by one, so we have the goal to do this automatically. This 
scenario is thought to be accomplished by creating external ports, this ports 
has to be created in an automatically way, to get that goal it must be created 
a set of overlay networks by configuring the devices in the way to the device 
that will be the host for the external port. This needs to be done, thinking 
that the devices on the external network are mostly heterogeneous and they must 
be configured automatically in a transparent way regardless of their 
characteristics and functional patterns.
My main concern is to decide which is the better way to do this. Can I go with 
the ML2 plugin and create a type driver and a mechanism driver to implement 
this virtual network extension as a new virtual network segment, or it would be 
better to implement it using the framework "Advanced Service Plugin" as a new 
type of service? In both possible solutions, we pretend to have an external 
agent to do the necessary configurations on the network devices.

Thank you,

Manuel Fernandes.






__
OpenStack Development Mailing 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] Nominating Julia Kreger for core reviewer

[Lucas Alvares Gomes]

Hi,

> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> the Bifrost project, gives super valuable reviews, is beginning to lead
> the boot from volume efforts, and is clearly an expert in this space.
>
> All in favor say +1 :)
>

+1 from me, welcome Julia!

__
OpenStack Development Mailing 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] [Infra] Cross-repository testing

[Sylwester Brzeczkowski]

Jeremy:

Thanks for your response! So the solution I proposed fits in common
openstack practices, that's cool.

I will definitely use zuul-cloner as it works for this case, but I would
use it inside our script and
then invoke the script in job macro. That will ensure that we will have the
same mechanism
working on local machine and on CI.

What do you think?

Regards

On Thu, Mar 24, 2016 at 2:50 PM, Jeremy Stanley  wrote:

> On 2016-03-24 11:44:16 +0100 (+0100), Sylwester Brzeczkowski wrote:
> > We want to enable proper testing for Nailgun (fuel-web) extensions. We
> want
> > to implement a script which will clone all required repos for test and
> > actually run the tests.
> >
> > The script will be placed in openstack/fuel-web [0] repo and should work
> > locally and also on openstack CI (gate jobs). All Nailgun Extensions
> should
> > have Nailgun in it's requirements so I think it's ok.
> >
> > What do you think about the idea? Is it a good approach?
> > Am I missing some already existing solutions for this problem?
> [...]
>
> This is basically what devstack-gate does for testing OpenStack
> deployments with DevStack. The logic for getting change dependencies
> right is far more complex than simply cloning a bunch of
> repositories. You need to make sure you try to fetch appropriate Zuul
> refs for all of them when available, fallback to sane branch
> selections when not all of the repos have the same branches, make
> use of repo caches for improved performance and update them to
> current state from our remote mirror, et cetera.
>
> Zuul includes a standalone command-line tool which also performs
> these operations, and we make it available on all our job workers at
> /usr/zuul-env/bin/zuul-cloner. Check job macros in the
> project-config directory for numerous examples of creating clonemaps
> and invoking zuul-cloner in jobs.
> --
> 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
>



-- 
*Sylwester Brzeczkowski*
Python Software Engineer
Product Development-Core : Product Engineering
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2016-03-24 21:30:34 +:
> On 2016-03-24 16:21:30 -0500 (-0500), Ian Cordasco wrote:
> > Also this only affects libraries and not the server projects.
> > Besides, hasn't this community always asserted that no one
> > installs from PyPI anyway (inspite of evidence of projects
> > allowing just that based on user feedback)?
> 
> The libraries are tagging in master AFAIK. The
> {name}-merge-release-tags jobs are run in the release pipeline for
> all projects using the openstack-server-release-jobs template in
> Zuul because those are the projects that needed it since they were
> the only ones traditionally tagging final releases on off-master
> branches:
> 
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml
> 

All of our projects are able to tag releases in master *and* stable
branches. We regularly release stable updates to libraries.

I'm embarrassed to say I don't know what the job you describe about
merging tags into master does. If the commit that was tagged on a stable
branch doesn't exist in master, what gets the tag in master? Or is the
stable branch commit merged back into master?

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] [Infra] Cross-repository testing

[Jeremy Stanley]

On 2016-03-25 13:31:02 +0100 (+0100), Sylwester Brzeczkowski wrote:
[...]
> I will definitely use zuul-cloner as it works for this case, but I
> would use it inside our script and then invoke the script in job
> macro. That will ensure that we will have the same mechanism
> working on local machine and on CI.
> 
> What do you think?

There are a number of projects already following that pattern as
well. http://codesearch.openstack.org/?q=zuul-cloner brings up
dozens of examples.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Anastasia Urlapova]

Dima,
if we want to deprecate UI logs in 10.0, it doesn't mean that we shouldn't
fix issues in 9.0.

Thank you!


Nastya.

On Fri, Mar 25, 2016 at 3:31 PM, Dmitry Pyzhov  wrote:

> As we are going to deprecate logs on UI I'm going to mark following bugs
> as "won't fix". Any objections?
> High priority bug:
> https://bugs.launchpad.net/fuel/+bug/1553170
> Medium priority:
> https://bugs.launchpad.net/fuel/+bug/1554546
> https://bugs.launchpad.net/fuel/+bug/1539508
>
> On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko 
> wrote:
>
>> Folks, I’ve registered a blueprint [1] and created an etherpad document
>> [2] where we can co-work on the spec before posting it to a formal review.
>> Let’s cooperate to summarize what we need to do.
>>
>>
>> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun
>> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun
>>
>> - romcheg
>>
>> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya 
>> написав(ла):
>> >
>> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
>> >> +1 to Vitaliy, it would be nice find somewhere a details for migration.
>> >> And one more concern I should highlight - for some users logless UI may
>> >> be challenging thing.
>> >> The logs removing shouldn't affect the UX.
>> >
>> > Logs will still live at the master node's /var/log/remote
>> >
>> >>
>> >>
>> >> Nastya.
>> >>
>> >>
>> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward > >> > wrote:
>> >>
>> >>I think we can address it by retaining deployment logs in
>> >>nailgun/ui, this also removes the chicken and egg problem. after LMA
>> >>is deployed it can be allowed to re-own 'logs' button on UI once
>> >>it's deployed, including redirecting fuel logs there.
>> >>
>> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
>> >>> wrote:
>> >>
>> >>We can sort out details later. In a worst case, the warning will
>> >>be there in Newton too, and feature will go away only in O*
>> >>release. So let's proceed with the bug..
>> >>
>> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
>> >>>
>> wrote:
>> >>
>> >>We can add the warning, but I think before we do this we
>> >>should have clear migration plan. According to this thread,
>> >>some parts are still not clear.
>> >>
>> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
>> >>> >>:
>> >>
>> >>Deprecation warning for Fuel
>> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.
>> >>
>> >>
>> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
>> >>> wrote:
>> >>
>> >>Since there are a lot of supporters for this idea,
>> >>what do you folks think about creating a BP spec
>> >>where we can describe what we should do in order to
>> >>remove logs from UI and Nailgun? I also propose to
>> >>file a bug about adding a deprecation warning to
>> >>Mitaka release of Fuel.
>> >>
>> >>
>> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
>> >>>> >>>> написав(ла):
>> >>>
>> >>>On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>> +1 to remove logs from Fuel UI in Fuel Newton.
>> In Fuel Mitaka we'd need to put a deprecation
>> warning somewhere.
>> >>>
>> >>>I agree, there is not much sense having non
>> >>>flexible (no content
>> >>>filters) logs view in UI. LMA plugins shall cover
>> >>>this area as well.
>> >>>
>> 
>> 
>> On Fri, Mar 11, 2016, 04:57 Patrick Petit
>> 
>> > wrote:
>> 
>> 
>>    On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>    (ikalnit...@mirantis.com
>>  > ikalnit...@mirantis.com>)
>> wrote:
>> 
>> >   Patrick,
>> >
>> >   Sorry, but I meant another question. I
>> >thought that LMA plugin should
>> >   be installed in some environment before we
>> >can start use it. Is
>> >   this a
>> > 

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Doug Hellmann]

Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> On 24/03/16 08:01, Doug Hellmann wrote:
> > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35 +1000:
> >> Hi Mike, and sorry I missed you on IRC to discuss this there. That said, I 
> >> think it's great that you took this to the mailing list, especially seeing 
> >> the conversation that has ensued.
> >>
> >> More inline ...
> >>
> >> On 24/03/16 01:06, Mike Perez wrote:
> >>> Hey all,
> >>>
> >>> I've been talking to a variety of projects about lack of install guides. 
> >>> This
> >>> came from me not having a great experience with trying out projects in 
> >>> the big
> >>> tent.
> >>>
> >>> Projects like Manila have proposed install docs [1], but they were 
> >>> rejected
> >>> by the install docs team because it's not in defcore. One of Manila's 
> >>> goals of
> >>> getting these docs accepted is to apply for the operators tag
> >>> ops:docs:install-guide [2] so that it helps their maturity level in the 
> >>> project
> >>> navigator [3].
> >>>
> >>> Adrian Otto expressed to me having the same issue for Magnum. I think it's
> >>> funny that a project that gets keynote time at the OpenStack conference 
> >>> can't
> >>> be in the install docs personally.
> >>>
> >>> As seen from the Manila review [1], the install docs team is suggesting 
> >>> these
> >>> to be put in their developer guide.
> >>
> >> As Steve pointed out, these now have solid plans to go in. That was 
> >> because both projects opened a conversation with us and we worked with 
> >> them over time to give them the docs they required.
> >>
> >>>
> >>> I don't think this is a great idea. Mainly because they are for 
> >>> developers,
> >>> operators aren't going to be looking in there for install information. 
> >>> Also the
> >>> Developer doc page [4] even states "This page contains documentation for 
> >>> Python
> >>> developers, who work on OpenStack itself".
> >>
> >> I agree, but it's a great place to start. In fact, I've just merged a 
> >> change to the Docs Contributor Guide (on the back of a previous mailing 
> >> list conversation) that explicitly states this:
> >>
> >> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > 
> > I think you're missing that most of us are disagreeing that it is
> > a good place to start. It's fine to have the docs in a repository
> > managed by the project team. It's not good at all to publish them
> > under docs.o.o/developer because they are not for developers, and
> > so it's confusing. This is why we ended up with a different place
> > for release notes to be published, instead of just adding reno to
> > the existing developer documentation build, for example.
> > 
> 
> All docs need to be drafted somewhere. I don't care where that is, but make 
> the suggestion of /developer because at least it's accessible there, and also 
> because it's managed in the project's own repo. If you want to create a 
> different place, or rename /developer to be more inclusive, I think that's a 
> great idea.

I think we'll want to add a new location, or publish to a similar
location to the existing install guide. I found, for example
http://docs.openstack.org/mitaka/install-guide-ubuntu/

If we take ironic as the example, and assume all OS-types would be
covered in one manual, we could make that:

(1) http://docs.openstack.org/mitaka/ironic/install-guide/
(2) http://docs.openstack.org/ironic/mitaka/install-guide/
(3) http://docs.openstack.org/install-guide/ironic/
(4) http://docs.openstack.org/ironic/install-guide/

I like options 3 and 4. To keep things simple for the project teams,
I think we want to skip including the release series in the base
URL.  As the instructions change, projects may need to create
separate sub-sections of their guide for each series, but they
should be able to do that without having to set up separate publishing
locations and jobs.

Another benefit of options 3 and 4 is that as the ironic team
produces other guides, those can go under a consistent URL that
makes it relatively simple to set up a generic publishing job for
all projects. Option 4 does have the benefit of making it easy to
have a page at http://docs.openstack.org/ironic/ linking to all of
the guides the ironic team has published.

Thoughts?

> > Right. The solution to that isn't to say "we aren't going to document
> > it at all" or "publish the documentation somewhere less ideal",
> > though, which is what it sounds like we're doing now.  It's to say
> 
> Actually, I said that I acknowledge that isn't working, and we need to find a 
> different solution.

OK, that wasn't clear to me from your message that continued to suggest
publishing to a location under /developer.

Doug

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

Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

[Tan, Lin]

+1! Always grateful for the invaluable comments from Julia

From: Vladyslav Drok [mailto:vd...@mirantis.com]
Sent: Friday, March 25, 2016 5:16 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [ironic] Nominating Julia Kreger for core reviewer

+1!

On Fri, Mar 25, 2016 at 4:03 AM, Zhenguo Niu 
> wrote:
+1, thanks for all the hard work Julia!

On Fri, Mar 25, 2016 at 8:39 AM, 守屋哲 / MORIYA，SATORU 
> wrote:
+1 for me. She has given lots of valuable reviews to boot from volume effort.
Thanks Julia!

Satoru

> -Original Message-
> From: Jim Rollenhagen 
> [mailto:j...@jimrollenhagen.com]
> Sent: Friday, March 25, 2016 4:09 AM
> To: 
> openstack-dev@lists.openstack.org
> Subject: [!][openstack-dev] [ironic] Nominating Julia Kreger for core reviewer
>
> Hey all,
>
> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> the Bifrost project, gives super valuable reviews, is beginning to lead
> the boot from volume efforts, and is clearly an expert in this space.
>
> All in favor say +1 :)
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Best Regards,
Zhenguo Niu

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

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

[openstack-dev] [release][stable][ironic] ironic-lib 1.2.0 release (mitaka)

[no-reply]

We are pumped to announce the release of:

ironic-lib 1.2.0: Ironic common library

This release is part of the mitaka stable release series.

With package available at:

https://pypi.python.org/pypi/ironic-lib

For more details, please see below.

Changes in ironic-lib 1.1.0..1.2.0
--

d497c51 Updated from global requirements
f107308 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 5cfcbd3..57f91a6 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ oslo.concurrency>=3.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



__
OpenStack Development Mailing 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] Wiping node's disks on delete

[Dmitry Guryanov]

I've read carefully the article about bios_grub partition you've given link
to. And it turned out for me that it's only used for non-UEFI boot. It this
case it's impossible to boot without stage1 (in mbr), because our PXE
doesn't touch hard disks. So clearing BIOS_boot partition will not
introduce any advantages. I suggest that we just clear boot code in mbr,
let's don't add unneeded code.

On Thu, Mar 24, 2016 at 2:13 PM, Alexander Gordeev 
wrote:

>
>
> On Wed, Mar 23, 2016 at 7:49 PM, Dmitry Guryanov 
> wrote:
>
>>
>> I have no objections against clearing bios boot partition, but could
>> you describe scenario, how non-efi system will boot with valid
>> BIOS_grub and wiped boot code in MBR
>>
>
>
> I thoroughly agree that it's impossible to boot without stage1 from the
> disk for non-uefi system. Besides, it doesn't mean what we shouldn't wipe
> dedicated BIOS_grub partition.
>
> But... How about network booting over PXE? I'm not quire sure if it's
> still technically possible. I read that stage1 just contains of LBA48
> pointer to the stage1.5 or stage2. So, i can imagine a case when somebody
> has tweaked PXE loader so it will be jumping to predefined LBA48 pointer
> where stage1.5/2 resides absolutely bypassing stage1.
>
> I knew that partitioning layout for the first 2 partitions is always the
> same for all target nodes. The actual value of the partitioning boundaries
> may slightly vary due to partition boundaries alignment depending on the
> h/w itself. If all nodes were equipped with the identical h/w (which is
> almost true for real deployments), then BIOS_grub partition resides under
> the same LBA48 pointer for all nodes. So, even it may be sounded too tricky
> and requires a lot of manual steps, but it's still possible. No? Did I miss
> something?
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dmitry Guryanov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][stable][keystone] pycadf 2.2.0 release (mitaka)

[no-reply]

We are content to announce the release of:

pycadf 2.2.0: CADF Library

This release is part of the mitaka stable release series.

With source available at:

https://git.openstack.org/cgit/openstack/pycadf

With package available at:

https://pypi.python.org/pypi/pycadf

Please report issues through launchpad:

https://bugs.launchpad.net/pycadf

For more details, please see below.

Changes in pycadf 2.1.0..2.2.0
--

c7d1a98 Updated from global requirements
dc53c9f Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 15ad583..410fbfb 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4 +4 @@
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0



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

[openstack-dev] [release][stable][keystone] keystonemiddleware 4.4.0 release (mitaka)

[no-reply]

We are satisfied to announce the release of:

keystonemiddleware 4.4.0: Middleware for OpenStack Identity

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystonemiddleware

With package available at:

https://pypi.python.org/pypi/keystonemiddleware

Please report issues through launchpad:

http://bugs.launchpad.net/keystonemiddleware

For more details, please see below.

Changes in keystonemiddleware 4.3.0..4.4.0
--

a0a1e4f Updated from global requirements
45f940b Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview   | 1 +
requirements.txt | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 733e4a9..0a9f2f3 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ keystoneauth1>=2.1.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0
@@ -10 +10 @@ oslo.serialization>=1.10.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0



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

[openstack-dev] [release][stable][keystone] keystoneauth1 2.4.0 release (mitaka)

[no-reply]

We are thrilled to announce the release of:

keystoneauth1 2.4.0: Authentication Library for OpenStack Identity

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/keystoneauth

With package available at:

https://pypi.python.org/pypi/keystoneauth1

Please report issues through launchpad:

http://bugs.launchpad.net/keystoneauth

For more details, please see below.

Changes in keystoneauth1 2.3.0..2.4.0
-

63267fa Updated from global requirements
666b993 Update .gitreview for stable/mitaka

Diffstat (except docs and test files)
-

.gitreview| 1 +
test-requirements.txt | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index ba8eec3..ad06c08 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -12 +12 @@ mock>=1.2 # BSD
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.7.0 # Apache-2.0
@@ -14 +14 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0



__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Dmitry Pyzhov]

As we are going to deprecate logs on UI I'm going to mark following bugs as
"won't fix". Any objections?
High priority bug:
https://bugs.launchpad.net/fuel/+bug/1553170
Medium priority:
https://bugs.launchpad.net/fuel/+bug/1554546
https://bugs.launchpad.net/fuel/+bug/1539508

On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko  wrote:

> Folks, I’ve registered a blueprint [1] and created an etherpad document
> [2] where we can co-work on the spec before posting it to a formal review.
> Let’s cooperate to summarize what we need to do.
>
>
> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun
> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun
>
> - romcheg
>
> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya 
> написав(ла):
> >
> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
> >> +1 to Vitaliy, it would be nice find somewhere a details for migration.
> >> And one more concern I should highlight - for some users logless UI may
> >> be challenging thing.
> >> The logs removing shouldn't affect the UX.
> >
> > Logs will still live at the master node's /var/log/remote
> >
> >>
> >>
> >> Nastya.
> >>
> >>
> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward  >> > wrote:
> >>
> >>I think we can address it by retaining deployment logs in
> >>nailgun/ui, this also removes the chicken and egg problem. after LMA
> >>is deployed it can be allowed to re-own 'logs' button on UI once
> >>it's deployed, including redirecting fuel logs there.
> >>
> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
> >>> wrote:
> >>
> >>We can sort out details later. In a worst case, the warning will
> >>be there in Newton too, and feature will go away only in O*
> >>release. So let's proceed with the bug..
> >>
> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
> >>>
> wrote:
> >>
> >>We can add the warning, but I think before we do this we
> >>should have clear migration plan. According to this thread,
> >>some parts are still not clear.
> >>
> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
> >> >>:
> >>
> >>Deprecation warning for Fuel
> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.
> >>
> >>
> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
> >>> wrote:
> >>
> >>Since there are a lot of supporters for this idea,
> >>what do you folks think about creating a BP spec
> >>where we can describe what we should do in order to
> >>remove logs from UI and Nailgun? I also propose to
> >>file a bug about adding a deprecation warning to
> >>Mitaka release of Fuel.
> >>
> >>
> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
> >>> >>>> написав(ла):
> >>>
> >>>On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
> +1 to remove logs from Fuel UI in Fuel Newton.
> In Fuel Mitaka we'd need to put a deprecation
> warning somewhere.
> >>>
> >>>I agree, there is not much sense having non
> >>>flexible (no content
> >>>filters) logs view in UI. LMA plugins shall cover
> >>>this area as well.
> >>>
> 
> 
> On Fri, Mar 11, 2016, 04:57 Patrick Petit
> 
> > wrote:
> 
> 
>    On 11 March 2016 at 12:51:40, Igor Kalnitsky
>    (ikalnit...@mirantis.com
>   ikalnit...@mirantis.com>)
> wrote:
> 
> >   Patrick,
> >
> >   Sorry, but I meant another question. I
> >thought that LMA plugin should
> >   be installed in some environment before we
> >can start use it. Is
> >   this a
> >   case? If so, it means we can't use for master
> >node until some
> >   environment is deployed.
> 
>    Right. This is the chicken and egg problem I
> mentioned earlier...
> 
>    But 

[openstack-dev] [oslo][messaging][zmq][performance]

[Oleksii Zamiatin]

Hi everyone!

Here is the status update for zmq driver upstream development in M and plans 
for N

What was done:

1. Dedicated patterns usage was finally impelemented. DEALER/ROUTER for CALL, 
PUSH/PULL for CAST, PUB/SUB for fanout.
Last time everything worked over DEAL/ROUTER which was not optimal 
enough.
2. Implemented support for Sentinel clustering in matchmaker Redis (Ty Alexey 
Yelistratov).
3. More smart (retries based) conversation between redis and services.
* Dynamic updates
* Records TTL
4. Transport URL was finally supported.
5. Added full tempest gate with Neutron for zmq (Ty Dmitry Ukhlov).
6. Performed successful multi-node deployment testing (Ty Alexey Yelistratov):
* devstack multiple nodes
* Rally nova-boot 200 nodes + fuel deployment
7. Performed benchmark testing with simulator (o.m/tools/simulator.py) on 20 
nodes deployment (Ty Yulia Portnova)
* CALL ~29k msg/sec compared to rabbit-cluster ~2k msg/sec
8. Finally reduced IPC-proxy which could cause problems in container-based 
deployment like koala.

And many other smaller bug-fixes.


So, we've got closer to zmq usage in real environment but still need more work 
to do to make this happen.
Here is the list of known issues we've got from testing as a feedback and other 
things we would like to fix in the driver.
(To find the whole list of known bugs please follow the link [1]).

Most important issues to fix in N here:

1. ZMQ driver eats too many TCP sockets [2].
Currently with direct client-server connections architecture we faced 
the problem. Solution is to use
stateless transparent remote-proxies to reduce the number of 
connections. The solution is in progress [3].

2. Implement retries for unacknowledged messages and heartbeats [4], [5], [6]
In order to have reliable messaging in case of bad-network and proxies 
failures.

3. Fix interaction with name-service and make proper updates both sides 
(HA-related) [7]
Properly reconnect restarted services.

4. Get success with ceilometer. [8]

5. Support PGM protocol for multicast as an option [9]

6. Support encryption for messages (libsodium etc.)

All other issues by the link [1]


What kinds of testing is planned:

1. HA testing:
* Restarting/adding/removing nodes, test reconnects and proper 
messaging layer recovery send-retries etc.
* Bad network emulation also test send-retries correctness

2. Benchmark testing:
* increase load, number of nodes
* test different kinds of deployment configuration (with different 
number of proxies, with direct connections).

3. Try Rally with 500 nodes at least.

Many thanks to Oslo and Performance teams for help with testing and reviews.

Thanks,
Oleksii

Links:
1 - https://bugs.launchpad.net/oslo.messaging/+bugs?field.tag=zmq
2 - https://bugs.launchpad.net/oslo.messaging/+bug/1555007
3 - https://review.openstack.org/#/c/287094/
4 - https://bugs.launchpad.net/oslo.messaging/+bug/1497306
5 - https://bugs.launchpad.net/oslo.messaging/+bug/1503295
6 - https://bugs.launchpad.net/oslo.messaging/+bug/1497302
7 - https://bugs.launchpad.net/oslo.messaging/+bug/1548836
8 - https://bugs.launchpad.net/oslo.messaging/+bug/1539047
9 - https://bugs.launchpad.net/oslo.messaging/+bug/1524100
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Doug Hellmann]

Excerpts from David Moreau Simard's message of 2016-03-24 16:56:55 -0400:
> On Thu, Mar 24, 2016 at 1:58 PM, Doug Hellmann  wrote:
> > Let's turn the question around: Why do you (or anyone) want to
> > package things that are not tagged as releasable by the contributors
> > creating them? What are those packages used for?
> 
> I know Ubuntu provides similar trunk repositories [1] but I'll reply
> to this specific bit from the RDO perspective.
> 
> TL;DR:
> It's a lot of work to package OpenStack and we can't realistically
> ship quickly if we only start working once a stable release is done.
> Consumers (end users and deployment projects) of RDO packages have the
> same need - to keep up with trunk to do a stable release ASAP.
> 
> The long version:
> RDO is first and foremost a community packaging effort of OpenStack
> for Red Hat based distributions.
> 
> There are two main reasons why we keep up with trunk for packages
> throughout the whole cycle:

[good reasoning snipped]

OK, the reasons for having trunk packages built from untagged commits
make sense. As a consumer of those packages, how do I indicate that I
want Liberty vs. Mitaka vs. master?

[more snipped]

> At the risk of tooting my own horn a bit here, I went a bit more in
> depth into how RDO keeps up with trunk in a talk I've done recently
> [3] if you're interested.

Thanks, I'll put that in my watch queue.

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] [OpenStack-Dev][Manila] BP https://blueprints.launchpad.net/manila/+spec/access-group

[nidhi.hada]

Hi All,

A gentle reminder..

Could you please share your thoughts on the approach proposed here ..

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

Thanks
Nidhi











From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Wednesday, March 09, 2016 2:22 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 

Cc: 'bswa...@netapp.com' ; 'Ben Swartzlander' 

Subject: RE: [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-groups

Hi All,

This is just a gentle reminder to the previous mail ..

PFA is revised doc.

Same is pasted here also.
https://etherpad.openstack.org/p/access_group_nidhimittalhada

Kindly share your thoughts on this..

Thanks
Nidhi



From: Nidhi Mittal Hada (Product Engineering Service)
Sent: Friday, February 26, 2016 3:22 PM
To: 'OpenStack Development Mailing List (not for usage questions)' 
>
Cc: 'bswa...@netapp.com' >; 'Ben 
Swartzlander' >
Subject: [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-groups

Hi Manila Team,

I am working on
https://blueprints.launchpad.net/manila/+spec/access-groups

For this I have created initial document as attached with the mail.
It contains DB CLI REST API related changes.

Could you please have a look and share your opinion.

Kindly let me know, if there is some understanding gap,
or something I have missed to document or
share your comments in general to make it better.

Thank you.
Nidhi Mittal Hada
Architect | PES / COE - Kolkata India
Wipro Limited
M +91 74 3910 9883 | O +91 33 3095 4767 | VOIP +91 33 3095 4767



The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.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] Deleting a cluster in Sahara SQL/PyMYSQL Error

[Mike Bayer]

and on the subject of"more folks reading this message", here's that 
bug report!   https://bugs.launchpad.net/sahara/+bug/1561807




On 03/25/2016 12:42 AM, Vitaly Gridnev wrote:

Hi. Thanks for your bug report! Also I would recommend to add
appropriate tags in future (like sahara in our case) to subject of the
message so that more folks can read this message.

Let's continue discussions about the bug in launchpad.

On Fri, Mar 25, 2016 at 4:23 AM, Jerico Revote > wrote:

Yes, first, when creating a new cluster, it get stuck on "validating",
then tried deleting it but get stuck again on "deleting",
and seeing that SQL error.
Will submit a bug @ Launchpad.

On 25 March 2016 at 01:56, Mike Bayer > wrote:

Id recommend filing a bug in Launchpad against Sahara for that.
Can you reproduce it ?




On 03/23/2016 07:10 PM, Jerico Revote wrote:

Hello,

When trying to delete a cluster in sahara,
I'm getting the following error:

code 500 and message 'Internal Server Error'
2016-03-23 17:25:21.651 18827  ERROR
sahara.utils.api
[req-d797bbc8-7932-4187-a428-565f9d834f8b ] Traceback
(most recent
call last):
OperationalError: (pymysql.err.OperationalError) (2014,
'Command Out
of Sync')
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
[req-377ef364-f2c7-4343-b32c-3741bfc0a05b ] DB exception
wrapped.
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
Traceback (most recent call last):
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py",
line 1139, in _execute_context
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  context)
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py",
line 450, in do_execute
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  cursor.execute(statement, parameters)
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/pymysql/cursors.py",
line 132,
in execute
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  result = self._query(query)
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/pymysql/cursors.py",
line 271,
in _query
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  conn.query(q)
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/pymysql/connections.py",
line
726, in query
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  self._affected_rows =
self._read_query_result(unbuffered=unbuffered)
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/pymysql/connections.py",
line
861, in _read_query_result
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  result.read()
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/pymysql/connections.py",
line
1064, in read
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  first_packet = self.connection._read_packet()
2016-03-23 17:25:35.803 18823 ERROR
oslo_db.sqlalchemy.exc_filters
  File
"/usr/lib/python2.7/dist-packages/pymysql/connections.py",
line
825, in _read_packet
2016-03-23 17:25:35.803 18823 ERROR
 

[openstack-dev] [Fuel][Library][Packaging] Build fuel-library as deb package

[Vitaly Parakhin]

Hello Fuelers,

Currently we install fuel-library package on the master node and then
copy Puppet modules to environment nodes using rsync.
The main disadvantage here is the additional logic required to
establish matching between different releases and corresponding Puppet
stuff.

The solution we propose is to use packaged versions of Puppet scripts
on environment nodes.
With this patch [0] we made the very first step towards debianization
of fuel-library.

Further plans include [1]:

* separate packaging of each upstream Puppet module
* replace rsync'ing of Puppet modules and manifests with fuel-library
package installation

Kindly ask you to review the patch [0]

[0] https://review.openstack.org/#/c/294653/
[1] https://review.openstack.org/#/c/293530/




-- 
Regards,
Vitaly Parakhin.
Infra Build Engineer | Mirantis, Inc. | http://www.mirantis.com
IRC: brain461 @ chat.freenode.net | Slack: vparakhin

__
OpenStack Development Mailing 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] Wiping node's disks on delete

[Dmitry Guryanov]

Here is the bug which I'm trying to fix -
https://bugs.launchpad.net/fuel/+bug/1538587.

In  VMs (set up with fuel-virtualbox) kernel panic occurs every time you
delete node, stack trace shows error in ext4 driver [1].
The same as in the bug.

Here is a patch - https://review.openstack.org/297669 . I've checked it
with virtual box VMs and it works fine.

I propose also don't reboot nodes in case of kernel panic, so that we'll
catch possible errors, but maybe it's too dangerous before release.

[1]
[13607.545119] EXT4-fs error (device dm-0) in
ext4_reserve_inode_write:4928: IO failure
[13608.157968] EXT4-fs error (device dm-0) in
ext4_reserve_inode_write:4928: IO failure
[13608.780695] EXT4-fs error (device dm-0) in
ext4_reserve_inode_write:4928: IO failure
[13609.471245] Aborting journal on device dm-0-8.
[13609.478549] EXT4-fs error (device dm-0) in ext4_dirty_inode:5047: IO
failure
[13610.069244] EXT4-fs error (device dm-0) in ext4_dirty_inode:5047: IO
failure
[13610.698915] Kernel panic - not syncing: EXT4-fs (device dm-0): panic
forced after error
[13610.698915]
[13611.060673] CPU: 0 PID: 8676 Comm: systemd-udevd Not tainted
3.13.0-83-generic #127-Ubuntu
[13611.236566] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[13611.887198]  fffb 88003b6e9a08 81725992
81a77878
[13612.527154]  88003b6e9a80 8171e80b 0010
88003b6e9a90
[13613.037061]  88003b6e9a30 88003b6e9a50 8800367f2ad0
0040
[13613.717119] Call Trace:
[13613.927162]  [] dump_stack+0x45/0x56
[13614.306858]  [] panic+0xc8/0x1e1
[13614.767154]  [] ext4_handle_error.part.187+0xa6/0xb0
[13615.187201]  [] __ext4_std_error+0x7b/0x100
[13615.627960]  [] ext4_reserve_inode_write+0x44/0xa0
[13616.007943]  [] ? ext4_dirty_inode+0x40/0x60
[13616.448084]  [] ext4_mark_inode_dirty+0x44/0x1f0
[13616.917611]  [] ? __ext4_journal_start_sb+0x69/0xe0
[13617.367730]  [] ext4_dirty_inode+0x40/0x60
[13617.747567]  [] __mark_inode_dirty+0x10a/0x2d0
[13618.088060]  [] update_time+0x81/0xd0
[13618.467965]  [] file_update_time+0x80/0xd0
[13618.977649]  [] __generic_file_aio_write+0x180/0x3d0
[13619.467993]  [] generic_file_aio_write+0x58/0xa0
[13619.978080]  [] ext4_file_write+0xa2/0x3f0
[13620.467624]  [] ? free_hot_cold_page_list+0x46/0xa0
[13621.038045]  [] ? release_pages+0x80/0x210
[13621.408080]  [] do_sync_write+0x5a/0x90
[13621.818155]  [] do_acct_process+0x4e6/0x5c0
[13622.278005]  [] acct_process+0x71/0xa0
[13622.597617]  [] do_exit+0x80f/0xa50
[13622.968015]  [] ? fput+0xe/0x10
[13623.337738]  [] do_group_exit+0x3f/0xa0
[13623.738020]  [] SyS_exit_group+0x14/0x20
[13624.137447]  [] system_call_fastpath+0x1a/0x1f
[13624.518044] Rebooting in 10 seconds..

On Tue, Mar 22, 2016 at 1:07 PM, Dmitry Guryanov 
wrote:

> Hello,
>
> Here is a start of the discussion -
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/083021.html
> . I've subscribed to this mailing list later, so can reply there.
>
> Currently we clear node's disks in two places. The first one is before
> reboot into bootstrap image [0] and the second - just before provisioning
> in fuel-agent [1].
>
> There are two problems, which should be solved with erasing first megabyte
> of disk data: node should not boot from hdd after reboot and new
> partitioning scheme should overwrite the previous one.
>
> The first problem could be solved with zeroing first 512 bytes of each
> disk (not partition). Even 446 to be precise, because last 66 bytes are
> partition scheme, see
> https://wiki.archlinux.org/index.php/Master_Boot_Record .
>
> The second problem should be solved only after reboot into bootstrap.
> Because if we bring a new node to the cluster from some other place and
> boot it with bootstrap image it will possibly have disks with some
> partitions, md devices and lvm volumes. So all these entities should be
> correctly cleared before provisioning, not before reboot. And fuel-agent
> does it in [1].
>
> I propose to remove erasing first 1M of each partiton, because it can lead
> to errors in FS kernel drivers and kernel panic. An existing workaround,
> that in case of kernel panic we do reboot is bad because it may occur just
> after clearing first partition of the first disk and after reboot bios will
> read MBR of the second disk and boot from it instead of network. Let's just
> clear first 446 bytes of each disk.
>
>
> [0]
> https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb#L162-L174
> [1]
> https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L194-L221
>
>
> --
> Dmitry Guryanov
>



-- 
Dmitry Guryanov
__
OpenStack Development Mailing 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] Nominating Julia Kreger for core reviewer

[Mathieu Mitchell]

On 2016-03-24 3:08 PM, Jim Rollenhagen wrote:

Hey all,

I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
the Bifrost project, gives super valuable reviews, is beginning to lead
the boot from volume efforts, and is clearly an expert in this space.

All in favor say +1 :)


+1, very knowledgeable, she is great asset for the team :)

Congratulations Julia!

Mathieu

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

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2016-03-25 12:50:04 +:
> On 2016-03-25 08:41:51 -0400 (-0400), Doug Hellmann wrote:
> > All of our projects are able to tag releases in master *and* stable
> > branches. We regularly release stable updates to libraries.
> > 
> > I'm embarrassed to say I don't know what the job you describe about
> > merging tags into master does. If the commit that was tagged on a stable
> > branch doesn't exist in master, what gets the tag in master? Or is the
> > stable branch commit merged back into master?
> 
> It was invented as a workaround for this problem:
> 
> 1. Create a new stable branch during the RC period.
> 2. Tag the first release on the new stable branch.
> 3. Compare dev versioning between new stable branch and master,
>you'll see that master's version is lower because it contains
>no record there's been a release tagged yet.
> 
> If the tag on the stable branch is higher than the tag on master, we
> merge the tag and its history into master but keep the current
> master branch state via this script:
> 
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/merge_tags.sh
> 
> It's possible that the logic there requires revisiting due to
> nuanced changes in our release model, but it should still be
> generally applicable.

OK. It looks like it grabs the tagged commit from the stable branch
and merges that back into master, expecting the results to be null
because we backport all changes to stable branches and don't introduce
anything new there. Is that right?

I think having the tags merged like that is going to confuse reno,
because I didn't expect us to be introducing a tag into the master
history that wasn't actually there. I'll have to experiment with
this to see if it really is a problem.

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] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Jeremy Stanley]

On 2016-03-25 09:14:27 -0400 (-0400), Doug Hellmann wrote:
> OK. It looks like it grabs the tagged commit from the stable branch
> and merges that back into master, expecting the results to be null
> because we backport all changes to stable branches and don't introduce
> anything new there. Is that right?

Not quite. Read the git-merge(1) bit about its "ours" merge strategy
(the -s/--strategy option we're passing in that script):

This resolves any number of heads, but the resulting tree of the
merge is always that of the current branch head, effectively
ignoring all changes from all other branches. It is meant to be
used to supersede old development history of side branches. Note
that this is different from the -Xours option to the recursive
merge strategy.

So it effectively allows us to merge in the missing Git history
(making the tag appear in master's branch history) without changing
the contents of any files on master. The actual contents of the
stable source branch and master target branch are irrelevant, since
we're telling git merge to ignore that completely.

> I think having the tags merged like that is going to confuse reno,
> because I didn't expect us to be introducing a tag into the master
> history that wasn't actually there. I'll have to experiment with
> this to see if it really is a problem.

Hopefully it's no different than if the tag already appeared in
multiple branches because of pre-dating the creation of a branch.
It's not actually pushing a new tag object and so no additional
release jobs are run by it. The result of this job is simply a merge
commit for review like any other change in Gerrit (albeit somewhat
confusing looking due to how Gerrit's UI chooses to represent the
conflict resolution in the merge, hence the somewhat verbose commit
message we include).
-- 
Jeremy Stanley

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

[openstack-dev] Which projects support wsgi / python3 in mitaka?

[Matthew Thode]

I'm updating the packaging for openstack in preparation for the release
and need some info to update correctly.  I'm specifically looking at the
following services.

I don't know if any of these services support python3 fully as a service
(liberty was kinda wishy washy on that).  Even if it supports python3,
which version, 3.4 or 3.4 or 3.5 (or multiple).

keystone - probably - keystone/server/wsgi.py
swift - don't think so
glance - maybe? - glance/api/ and glance/registry/ seems to have some
scripts, but not as simple as scrubber/registry/api.
cinder - probably - cinder/wsgi/wsgi.py
neutron - probably - neutron/server/wsgi_pecan.py
nova - probably - both in nova/wsgi/
heat - probably - three under heat/httpd/

Don't think docs are out yet (which would likely have some of this
info), but any info you have around this would help.

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

[openstack-dev] [zaqar] zaqar mitaka rc2 available

[Thierry Carrez]

Due to release-critical issues spotted in Zaqar during RC1 testing, a
new release candidate was created for Mitaka. You can find the RC2 
source code tarball at:


https://tarballs.openstack.org/zaqar/zaqar-2.0.0.0rc2.tar.gz

Unless new release-critical issues are found that warrant a last-minute
release candidate respin, this tarball will be formally released as the
final "Mitaka" version on April 7th. You are therefore strongly
encouraged to test and validate this tarball !

Alternatively, you can directly test the mitaka release branch at:
http://git.openstack.org/cgit/openstack/zaqar/log/?h=stable/mitaka

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/zaqar/+filebug

and tag it *mitaka-rc-potential* to bring it to the Zaqar release crew's
attention.

--
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] [Fuel] Wiping node's disks on delete

[Alex Schultz]

On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov 
wrote:

> Here is the bug which I'm trying to fix -
> https://bugs.launchpad.net/fuel/+bug/1538587.
>
> In  VMs (set up with fuel-virtualbox) kernel panic occurs every time you
> delete node, stack trace shows error in ext4 driver [1].
> The same as in the bug.
>
> Here is a patch - https://review.openstack.org/297669 . I've checked it
> with virtual box VMs and it works fine.
>
> I propose also don't reboot nodes in case of kernel panic, so that we'll
> catch possible errors, but maybe it's too dangerous before release.
>
>
The panic is in there to prevent controllers from staying active with a bad
disk. If the file system on a controller goes RO, the node stays in the
cluster and causes errors with the openstack deployment.  The node erase
code tries to disable this prior to erasing the disk so if it's not working
we need to fix that, not remove it.

Thanks,
-Alex


> [1]
> [13607.545119] EXT4-fs error (device dm-0) in
> ext4_reserve_inode_write:4928: IO failure
> [13608.157968] EXT4-fs error (device dm-0) in
> ext4_reserve_inode_write:4928: IO failure
> [13608.780695] EXT4-fs error (device dm-0) in
> ext4_reserve_inode_write:4928: IO failure
> [13609.471245] Aborting journal on device dm-0-8.
> [13609.478549] EXT4-fs error (device dm-0) in ext4_dirty_inode:5047: IO
> failure
> [13610.069244] EXT4-fs error (device dm-0) in ext4_dirty_inode:5047: IO
> failure
> [13610.698915] Kernel panic - not syncing: EXT4-fs (device dm-0): panic
> forced after error
> [13610.698915]
> [13611.060673] CPU: 0 PID: 8676 Comm: systemd-udevd Not tainted
> 3.13.0-83-generic #127-Ubuntu
> [13611.236566] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
> VirtualBox 12/01/2006
> [13611.887198]  fffb 88003b6e9a08 81725992
> 81a77878
> [13612.527154]  88003b6e9a80 8171e80b 0010
> 88003b6e9a90
> [13613.037061]  88003b6e9a30 88003b6e9a50 8800367f2ad0
> 0040
> [13613.717119] Call Trace:
> [13613.927162]  [] dump_stack+0x45/0x56
> [13614.306858]  [] panic+0xc8/0x1e1
> [13614.767154]  [] ext4_handle_error.part.187+0xa6/0xb0
> [13615.187201]  [] __ext4_std_error+0x7b/0x100
> [13615.627960]  [] ext4_reserve_inode_write+0x44/0xa0
> [13616.007943]  [] ? ext4_dirty_inode+0x40/0x60
> [13616.448084]  [] ext4_mark_inode_dirty+0x44/0x1f0
> [13616.917611]  [] ? __ext4_journal_start_sb+0x69/0xe0
> [13617.367730]  [] ext4_dirty_inode+0x40/0x60
> [13617.747567]  [] __mark_inode_dirty+0x10a/0x2d0
> [13618.088060]  [] update_time+0x81/0xd0
> [13618.467965]  [] file_update_time+0x80/0xd0
> [13618.977649]  [] __generic_file_aio_write+0x180/0x3d0
> [13619.467993]  [] generic_file_aio_write+0x58/0xa0
> [13619.978080]  [] ext4_file_write+0xa2/0x3f0
> [13620.467624]  [] ? free_hot_cold_page_list+0x46/0xa0
> [13621.038045]  [] ? release_pages+0x80/0x210
> [13621.408080]  [] do_sync_write+0x5a/0x90
> [13621.818155]  [] do_acct_process+0x4e6/0x5c0
> [13622.278005]  [] acct_process+0x71/0xa0
> [13622.597617]  [] do_exit+0x80f/0xa50
> [13622.968015]  [] ? fput+0xe/0x10
> [13623.337738]  [] do_group_exit+0x3f/0xa0
> [13623.738020]  [] SyS_exit_group+0x14/0x20
> [13624.137447]  [] system_call_fastpath+0x1a/0x1f
> [13624.518044] Rebooting in 10 seconds..
>
> On Tue, Mar 22, 2016 at 1:07 PM, Dmitry Guryanov 
> wrote:
>
>> Hello,
>>
>> Here is a start of the discussion -
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/083021.html
>> . I've subscribed to this mailing list later, so can reply there.
>>
>> Currently we clear node's disks in two places. The first one is before
>> reboot into bootstrap image [0] and the second - just before provisioning
>> in fuel-agent [1].
>>
>> There are two problems, which should be solved with erasing first
>> megabyte of disk data: node should not boot from hdd after reboot and new
>> partitioning scheme should overwrite the previous one.
>>
>> The first problem could be solved with zeroing first 512 bytes of each
>> disk (not partition). Even 446 to be precise, because last 66 bytes are
>> partition scheme, see
>> https://wiki.archlinux.org/index.php/Master_Boot_Record .
>>
>> The second problem should be solved only after reboot into bootstrap.
>> Because if we bring a new node to the cluster from some other place and
>> boot it with bootstrap image it will possibly have disks with some
>> partitions, md devices and lvm volumes. So all these entities should be
>> correctly cleared before provisioning, not before reboot. And fuel-agent
>> does it in [1].
>>
>> I propose to remove erasing first 1M of each partiton, because it can
>> lead to errors in FS kernel drivers and kernel panic. An existing
>> workaround, that in case of kernel panic we do reboot is bad because it may
>> occur just after clearing first partition of the first disk and after
>> reboot bios will read MBR of the second disk and boot from it instead of

Re: [openstack-dev] [Fuel] Wiping node's disks on delete

[Dmitry Guryanov]

On Fri, 2016-03-25 at 08:00 -0600, Alex Schultz wrote:
> 
> On Fri, Mar 25, 2016 at 7:32 AM, Dmitry Guryanov  com> wrote:
> > Here is the bug which I'm trying to fix - https://bugs.launchpad.ne
> > t/fuel/+bug/1538587.
> > 
> > In  VMs (set up with fuel-virtualbox) kernel panic occurs every
> > time you delete node, stack trace shows error in ext4 driver [1].
> > The same as in the bug.
> > 
> > Here is a patch - https://review.openstack.org/297669 . I've
> > checked it with virtual box VMs and it works fine.
> > 
> > I propose also don't reboot nodes in case of kernel panic, so that
> > we'll catch possible errors, but maybe it's too dangerous before
> > release.
> > 
> > 
> The panic is in there to prevent controllers from staying active with
> a bad disk. If the file system on a controller goes RO, the node
> stays in the cluster and causes errors with the openstack
> deployment.  The node erase code tries to disable this prior to
> erasing the disk so if it's not working we need to fix that, not
> remove it.

There will be no filesystem errors because of erasing disks with my
patch. The node will be fully operable until reboot.


> Thanks,
> -Alex
>  
> > [1]
> > [13607.545119] EXT4-fs error (device dm-0) in
> > ext4_reserve_inode_write:4928: IO failure
> > [13608.157968] EXT4-fs error (device dm-0) in
> > ext4_reserve_inode_write:4928: IO failure
> > [13608.780695] EXT4-fs error (device dm-0) in
> > ext4_reserve_inode_write:4928: IO failure
> > [13609.471245] Aborting journal on device dm-0-8.
> > [13609.478549] EXT4-fs error (device dm-0) in
> > ext4_dirty_inode:5047: IO failure
> > [13610.069244] EXT4-fs error (device dm-0) in
> > ext4_dirty_inode:5047: IO failure
> > [13610.698915] Kernel panic - not syncing: EXT4-fs (device dm-0):
> > panic forced after error
> > [13610.698915] 
> > [13611.060673] CPU: 0 PID: 8676 Comm: systemd-udevd Not tainted
> > 3.13.0-83-generic #127-Ubuntu
> > [13611.236566] Hardware name: innotek GmbH VirtualBox/VirtualBox,
> > BIOS VirtualBox 12/01/2006
> > [13611.887198]  fffb 88003b6e9a08 81725992
> > 81a77878
> > [13612.527154]  88003b6e9a80 8171e80b 0010
> > 88003b6e9a90
> > [13613.037061]  88003b6e9a30 88003b6e9a50 8800367f2ad0
> > 0040
> > [13613.717119] Call Trace:
> > [13613.927162]  [] dump_stack+0x45/0x56
> > [13614.306858]  [] panic+0xc8/0x1e1
> > [13614.767154]  []
> > ext4_handle_error.part.187+0xa6/0xb0
> > [13615.187201]  [] __ext4_std_error+0x7b/0x100
> > [13615.627960]  []
> > ext4_reserve_inode_write+0x44/0xa0
> > [13616.007943]  [] ? ext4_dirty_inode+0x40/0x60
> > [13616.448084]  []
> > ext4_mark_inode_dirty+0x44/0x1f0
> > [13616.917611]  [] ?
> > __ext4_journal_start_sb+0x69/0xe0
> > [13617.367730]  [] ext4_dirty_inode+0x40/0x60
> > [13617.747567]  [] __mark_inode_dirty+0x10a/0x2d0
> > [13618.088060]  [] update_time+0x81/0xd0
> > [13618.467965]  [] file_update_time+0x80/0xd0
> > [13618.977649]  []
> > __generic_file_aio_write+0x180/0x3d0
> > [13619.467993]  []
> > generic_file_aio_write+0x58/0xa0
> > [13619.978080]  [] ext4_file_write+0xa2/0x3f0
> > [13620.467624]  [] ?
> > free_hot_cold_page_list+0x46/0xa0
> > [13621.038045]  [] ? release_pages+0x80/0x210
> > [13621.408080]  [] do_sync_write+0x5a/0x90
> > [13621.818155]  [] do_acct_process+0x4e6/0x5c0
> > [13622.278005]  [] acct_process+0x71/0xa0
> > [13622.597617]  [] do_exit+0x80f/0xa50
> > [13622.968015]  [] ? fput+0xe/0x10
> > [13623.337738]  [] do_group_exit+0x3f/0xa0
> > [13623.738020]  [] SyS_exit_group+0x14/0x20
> > [13624.137447]  [] system_call_fastpath+0x1a/0x1f
> > [13624.518044] Rebooting in 10 seconds..
> > 
> > On Tue, Mar 22, 2016 at 1:07 PM, Dmitry Guryanov  > s.com> wrote:
> > > Hello,
> > > 
> > > Here is a start of the discussion - http://lists.openstack.org/pi
> > > permail/openstack-dev/2015-December/083021.html . I've subscribed
> > > to this mailing list later, so can reply there.
> > > 
> > > Currently we clear node's disks in two places. The first one is
> > > before reboot into bootstrap image [0] and the second - just
> > > before provisioning in fuel-agent [1].
> > > 
> > > There are two problems, which should be solved with erasing first
> > > megabyte of disk data: node should not boot from hdd after reboot
> > > and new partitioning scheme should overwrite the previous one.
> > > 
> > > The first problem could be solved with zeroing first 512 bytes of
> > > each disk (not partition). Even 446 to be precise, because last
> > > 66 bytes are partition scheme, see https://wiki.archlinux.org/ind
> > > ex.php/Master_Boot_Record .
> > > 
> > > The second problem should be solved only after reboot into
> > > bootstrap. Because if we bring a new node to the cluster from
> > > some other place and boot it with bootstrap image it will
> > > possibly have disks with some partitions, md devices and lvm
> > > volumes. So all these entities should be 

Re: [openstack-dev] Which projects support wsgi / python3 in mitaka?

[Ian Cordasco]

 

-Original Message-
From: Matthew Thode 
Reply: prometheanf...@gentoo.org , OpenStack 
Development Mailing List (not for usage questions) 

Date: March 25, 2016 at 09:57:53
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  [openstack-dev] Which projects support wsgi / python3 in mitaka?

> I'm updating the packaging for openstack in preparation for the release
> and need some info to update correctly. I'm specifically looking at the
> following services.
>  
> I don't know if any of these services support python3 fully as a service
> (liberty was kinda wishy washy on that). Even if it supports python3,
> which version, 3.4 or 3.4 or 3.5 (or multiple).
>  
> keystone - probably - keystone/server/wsgi.py
> swift - don't think so
> glance - maybe? - glance/api/ and glance/registry/ seems to have some
> scripts, but not as simple as scrubber/registry/api.
> cinder - probably - cinder/wsgi/wsgi.py
> neutron - probably - neutron/server/wsgi_pecan.py
> nova - probably - both in nova/wsgi/
> heat - probably - three under heat/httpd/
>  
> Don't think docs are out yet (which would likely have some of this
> info), but any info you have around this would help.

I believe the Python 3 team is tracking this information here: 
https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects

--  
Ian Cordasco


__
OpenStack Development Mailing 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] [kite] Seeking core reviewers

[Ronald Bradford]

Thanks all for feedback.

I have proposed a non maintained patch [1] based on comments here.
I will speak with the Barbican team.

Ronald

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


Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford 
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Mar 25, 2016 at 5:02 AM, Thierry Carrez 
wrote:

> Ian Cordasco wrote:
>
>> I believe Kite is no longer actively developed or maintained and was
>> started by the Barbican folks. You should find them in #openstack-barbican.
>>
>
> Yeah. It's still technically a repository under the Barbican team. Someone
> from Barbican should propose a governance change to get rid of it (or
> approve someone else's change getting rid of it).
>
> Keeping abandoned repositories in your official list does not reflect well
> on your project team (or OpenStack in general).
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Mitaka RC2 available

[Thierry Carrez]

Due to release-critical issues spotted in Neutron during RC1 testing, a 
new release candidate was created for Mitaka. You can find the RC2 
source code tarballs at:


https://tarballs.openstack.org/neutron/neutron-8.0.0.0rc2.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-8.0.0.0rc2.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-8.0.0.0rc2.tar.gz
https://tarballs.openstack.org/neutron-vpnaas/neutron-vpnaas-8.0.0.0rc2.tar.gz

Unless new release-critical issues are found that warrant a last-minute 
release candidate respin, these tarballs will be formally released as 
the final "Mitaka" version on April 7th. You are therefore strongly 
encouraged to test and validate these tarballs !


Alternatively, you can directly test the mitaka release branches at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/mitaka
http://git.openstack.org/cgit/openstack/neutron-lbaas/log/?h=stable/mitaka
http://git.openstack.org/cgit/openstack/neutron-fwaas/log/?h=stable/mitaka
http://git.openstack.org/cgit/openstack/neutron-vpnaas/log/?h=stable/mitaka

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/neutron/+filebug

and tag it *mitaka-rc-potential* to bring it to the Neutron release 
crew's attention.


--
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] [cinder] Does the OpenStack community(or Cinder team) allow one driver to call another driver's public method?

[Fox, Kevin M]

Sounds like a reasonable optimization, but may not always be possible. Take, 
for example, the ceph backend. For other backends that are appliances, they 
would have to be able to implement a ceph client that matches the version of 
the ceph servers in use. That might be very difficult to support.

So maybe allow it, but have some automatic fall back mechanism if it fails?

Thanks,
Kevin

From: liuxinguo [liuxin...@huawei.com]
Sent: Thursday, March 24, 2016 6:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Zhangli (ISSP); Luozhen
Subject: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder 
team) allow one driver to call another driver's public method?

Hi Jon,

My basic idea is that, when we need to migrate a volume from my (vendor of) 
storage array to another backend (storage array), we will firstly call the 
other backend's create_volume() to create a volume on the other backend,
and then we will take my backend (storage array) as a "host" and attach other 
backend's volume to our backend (storage array). And then we can migrate the 
volume from our storage array to other storage array directly and very 
efficiently.
And at last when the migration finished, we call the other backend's 
terminate_connection() to detach the volume from our storage array.

Of course, the precondition is that our backend array is connected (can copy 
data) to other backend array so we can migrate volume directly between them.

--
Wilson Liu

-邮件原件-
发件人: Jon Bernard [mailto:jbern...@tuxion.com]
发送时间: 2016年3月23日 4:44
收件人: OpenStack Development Mailing List (not for usage questions)
抄送: Luozhen
主题: Re: [openstack-dev] [cinder] Does the OpenStack community(or Cinder team) 
allow one driver to call another driver's public method?

* liuxinguo  wrote:
> Hi Cinder team,
>
> We are going to implement storage-assisted volume migrate in our
> driver between different backend storage array or even different array
> of different vendors.  This is really high-efficiency than the
> host-copy migration between different array of different vendors.

Could you elaborate more on this?  During a volume migration operation we give 
the driver an opportunity to more-intelligently relocate the volume's data.  
This is done through the migrate_volume() method defined in the driver itself.  
If this method exists, it will be called before falling back to a byte-for-byte 
copy approach - and if it succeeds the volume is considered migrated and the 
operation returns.

Is this what you were looking for, or did you have something different in mind?

--
Jon

__
OpenStack Development Mailing 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] [kolla][vote] deprecation of icehosue/juno/kilo branches

[Paul Bourke]

+1

On 25/03/16 15:36, Steven Dake (stdake) wrote:

Hey folks,

These branches are essentially unmaintained and we have completely given
up on them.  That’s ok – they were paths of our development.  I didn't
really want to branch them in the first place, but the community
demanded it, so I delivered that :)

Now that our architecture is fairly stable in liberty and mitaka, I
think it makes sense to do the following
1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol
2. Ask infrastructure to remove the branches from git

This is possible; I have just verified in openstack-infra.  I'd like a
vote from the core review team.  If you would like to see the kilo
branch stay, please note that, and if there is a majority on
icehosue/juno but not kilo I'll make the appropriate arrangements with
openstack-infra.

I will leave voting open for 1 week until Saturday April 2nd.  I will
close voting early if there is a majority vote.

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



__
OpenStack Development Mailing 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] Component Leads Elections

[Vladimir Kozhukalov]

Dear all,

Let me raise my hand here. We introduced this role CL a while ago for two
major reasons:
 1) improve review process (CL are responsible for review SLA)
 2) introduce review of overall architecture and avoid cross-feature,
cross-component conflicts.
These two points, in fact, mean the following:
 1) CL ask other developers (including cores) to help to review patches if
there any that did not get enough attention
 2) CL spend 50% of their time reviewing specs and we don't merge specs w/o
their +2

I think that is not exactly what we meant. Our CL role is rather a mixture
of a manager and an architect. Both these roles are enterprise roles. I
think in community having Core Reviewers is more than enough.

Real motivation (salary, career, etc.) of a particular contributor should
NOT be a matter of community. If a particular manager wants to have a
person who is to be responsible for asking people to review patches, then
it is a matter of this manager to motivate a particular person. In
community a team of core reviewers is responsible for review, not a person.

To prevent cross-feature and cross-component conflicts we can use CI gate
that will put -1 to a spec that is merged without necessary +2 from trusted
people from various components. For example, we could create a yaml file

avengers:
  fuel-web:
Hawkeye
Captain America
  fuel-ui:
Black Widow
  fuel-library
Hulk
Ironman

and CI gate will check if there is +2 from at least one superhero from
every project and fail if not. Superheros should be volunteers (no matter
what their real motivation is).

I propose to get rid of official CL role in Fuel. Instead it should be
totally up to a particular component team to decide if they want CL or
other roles. What do you guys think?

















Vladimir Kozhukalov

On Thu, Mar 24, 2016 at 11:58 PM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:

> Serg,
>
> Thanks for agreeing to officiate this cycle's component lead elections
> for us!
>
> --
> Dmitry Borodaenko
>
>
> On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote:
> > Hi folks,
> >
> > I'd like to announce that we're running the Component Leads elections.
> > Detailed information is available on wiki [0].
> >
> > Component Lead: defines architecture of a particular module or
> > component in Fuel, resolves technical disputes in their area of
> > responsibility. All design specs that impact a component must be
> > approved by the corresponding component lead [1].
> >
> > Fuel has three large sub-teams, with roughly comparable codebases,
> > that need dedicated component leads:
> >
> > * fuel-library
> > * fuel-web
> > * fuel-ui
> >
> > Nominees propose their candidacy by sending an email to the
> > openstack-dev@lists.openstack.org mailing-list, with the subject:
> > "[fuel]  lead candidacy"
> > (for example, "[fuel] fuel-library lead candidacy").
> >
> > Timeline:
> > * March 25 - March 31: Open candidacy for Component leads positions
> > * April 1 - April 7: Component leads elections
> >
> > References
> > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016
> > [1]
> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
> >
> > --
> > Serg Melikyan, Development Manager at Mirantis, Inc.
> > http://mirantis.com | smelik...@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
>
> __
> OpenStack Development Mailing 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] Which projects support wsgi / python3 in mitaka?

[Ian Cordasco]

 

-Original Message-
From: Matthew Thode 
Reply: prometheanf...@gentoo.org , OpenStack 
Development Mailing List (not for usage questions) 

Date: March 25, 2016 at 11:10:52
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] Which projects support wsgi / python3 in mitaka?

> On 03/25/2016 09:54 AM, Matthew Thode wrote:
> > I'm updating the packaging for openstack in preparation for the release
> > and need some info to update correctly. I'm specifically looking at the
> > following services.
> >
> > I don't know if any of these services support python3 fully as a service
> > (liberty was kinda wishy washy on that). Even if it supports python3,
> > which version, 3.4 or 3.4 or 3.5 (or multiple).
> >
> > keystone - probably - keystone/server/wsgi.py
> > swift - don't think so
> > glance - maybe? - glance/api/ and glance/registry/ seems to have some
> > scripts, but not as simple as scrubber/registry/api.
> > cinder - probably - cinder/wsgi/wsgi.py
> > neutron - probably - neutron/server/wsgi_pecan.py
> > nova - probably - both in nova/wsgi/
> > heat - probably - three under heat/httpd/
> >
> > Don't think docs are out yet (which would likely have some of this
> > info), but any info you have around this would help.
> Found the info around python3, just need confirmation on where to find
> those wsgi scripts :P
>  
> Thanks for the link Ian.
> https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects 
>  

Side note, depending on exactly which wsgi script you're looking for, pbr may 
generate them for you. For example, if a project has a wsgi_scripts entry-point 
in their setup.cfg, that will generate mod_wsgi scripts for an Apache 
deployment. That said, I expect that you should probably be using `python3 
setup.py` as the basis for your generation of those scripts.

Also, I think most of the services have entry-points generate the scripts that 
run things. I'm not certain you should be using the paths you described above 
directly.

Keystone definitely uses wsgi_scripts in its setup.cfg.

--  
Ian Cordasco


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

[openstack-dev] [release] proposed newton schedule

[Doug Hellmann]

The proposed release schedule for Newton is available at
http://releases.openstack.org/newton/schedule.html

Please note that we will be using Thursdays for deadlines next cycle
(that is, for the Feature Freeze at Newton-3 in week R-5 the deadline is
Sept 8).

Let us know here in this thread if you see any schedule conflicts.

Doug

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

[openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches

[Steven Dake (stdake)]

Hey folks,

These branches are essentially unmaintained and we have completely given up on 
them.  That's ok - they were paths of our development.  I didn't really want to 
branch them in the first place, but the community demanded it, so I delivered 
that :)

Now that our architecture is fairly stable in liberty and mitaka, I think it 
makes sense to do the following
1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol
2. Ask infrastructure to remove the branches from git

This is possible; I have just verified in openstack-infra.  I'd like a vote 
from the core review team.  If you would like to see the kilo branch stay, 
please note that, and if there is a majority on icehosue/juno but not kilo I'll 
make the appropriate arrangements with openstack-infra.

I will leave voting open for 1 week until Saturday April 2nd.  I will close 
voting early if there is a majority vote.

Regards
-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] [kite] Seeking core reviewers

[Douglas Mendizábal]

Thanks for the patches, Ronald.  Adam Young is right, Kite is pretty
much dead.

I'll add to my list of spring cleaning to-dos to remove Kite from
governance and infra.

Thanks,
Douglas Mendizábal (redrobot)

On 3/25/16 10:08 AM, Ronald Bradford wrote:
> Thanks all for feedback.
> 
> I have proposed a non maintained patch [1] based on comments here.
> I will speak with the Barbican team.
> 
> Ronald
> 
> [1] https://review.openstack.org/#/c/297719/
> 
> 
> Ronald Bradford
> 
> Web Site: http://ronaldbradford.com 
> LinkedIn:  http://www.linkedin.com/in/ronaldbradford
> Twitter:@RonaldBradford 
> Skype: RonaldBradford
> GTalk: Ronald.Bradford
> IRC: rbradfor
> 
> 
> On Fri, Mar 25, 2016 at 5:02 AM, Thierry Carrez  > wrote:
> 
> Ian Cordasco wrote:
> 
> I believe Kite is no longer actively developed or maintained and
> was started by the Barbican folks. You should find them in
> #openstack-barbican.
> 
> 
> Yeah. It's still technically a repository under the Barbican team.
> Someone from Barbican should propose a governance change to get rid
> of it (or approve someone else's change getting rid of it).
> 
> Keeping abandoned repositories in your official list does not
> reflect well on your project team (or OpenStack in general).
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



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

[openstack-dev] [nova][scheduler] Nova Scheduler sub-team meeting 2016-03-28

[Ed Leafe]

The next meeting for the Nova Scheduler sub-team will be on Monday,
March 28 at 1400 UTC
(http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160328T14)

The agenda for the meeting is here:
https://wiki.openstack.org/wiki/Meetings/NovaScheduler

Please edit that page to add any specific topics you would like to discuss.

-- 

-- Ed Leafe




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] [ironic] Nominating Julia Kreger for core reviewer

[Jim Rollenhagen]

On Fri, Mar 25, 2016 at 12:03:34PM -0400, Julia Kreger wrote:
> On Thu, Mar 24, 2016 at 3:08 PM, Jim Rollenhagen 
> wrote:
> 
> > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core.
> 
> 
> I would like to thank the academy for... oh wait... wrong speech.
> 
> It is not often one gets to see a flood of positive messages from a
> community, from the family that makes up Ironic.  And yes, I blushed.
> 
> Thank you everyone!

I see 8 cores in; sounds like consensus. Thank YOU, Julia, for your
awesome work. :)

Updating access lists now!

// jim

> 
> -Julia

> __
> OpenStack Development Mailing 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] [kite][barbican] Notice to retire kite and python-kiteclient projects

[Ronald Bradford]

>From the initial ML discussion [1], the following are instructions to
retire a project [2].
The kite and python_kiteclient projects are moving to a non maintained
status.

First is the removal of project gates. [3]
Second is updating code repos, [4],[5]. See README for how code can still
be accessed
Finally, is the removal of projects from infrastructure [6]


[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090409.html
[2] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
[3] https://review.openstack.org/#/c/297746/
[4] https://review.openstack.org/#/c/297719/
[5] https://review.openstack.org/#/c/297741/
[6] https://review.openstack.org/#/c/297738/
__
OpenStack Development Mailing 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][novaclient] host-evacuate-live command is broken in 3.3.0

[Sean M. Collins]

Hi,

3.3.0 of python-novaclient has a serious bug, which prevents host-evacuate-live 
from working correctly.

https://github.com/openstack/python-novaclient/commit/ae598280acc46dd4ee20af78a5780a450f96b084
 appears to have changed a number of function signatures and arguments, and 
resulted in the breakage.

I have filed a bug with all the details of my findings, but I wanted to
bring it to the attention of a wider audience.

https://bugs.launchpad.net/python-novaclient/+bug/1561938

How do we proceed? Revert ae598280 ? 
-- 
Sean M. Collins

__
OpenStack Development Mailing 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] NaaS using Openstack Neutron

[Fox, Kevin M]

There's two different pieces of software that exist that may handle the use 
case, depending on what you want to do.

the neutron l2gw project:
http://docs.openstack.org/developer/networking-l2gw/usage.html

I believe it creates a gateway node to bridge between the tenant networks and 
phyiscal ones, so that you can attach non neutron devices to neutron networks.

The second, is a script I wrote and have been using in production for a while 
that binds a neutron openvswitch agent supporting host directly to a tenant 
network. This eliminates any performance penalties with going through a gateway 
system. But can't really be used with appliances.

Its not the prettiest of scripts yet, but would be a good starting point if 
your interested. Code is here:
https://review.openstack.org/#/c/158003/

Thanks,
Kevin


From: Manuel Fernandes [manuelfernande...@gmail.com]
Sent: Friday, March 25, 2016 5:52 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] NaaS using Openstack Neutron

Hello to all,

My name is Manuel, I'm a MsC student in Computing and Telematics engineering at 
the University of Aveiro in Portugal and I'm currently working on my MsC 
thesis, which the topic is "Network as a Service (NaaS) using Openstack - 
Neutron". My main goal is to get a way to extend the virtual networks created 
in Openstack to the network outside of the datacenter (for example a campus 
network) to get external devices on the same L2 domain as the VMs on the 
virtual network, now this scenario is possible using the extension "Provider 
Network", but the external network operator needs to configure all the devices 
manually one by one, so we have the goal to do this automatically. This 
scenario is thought to be accomplished by creating external ports, this ports 
has to be created in an automatically way, to get that goal it must be created 
a set of overlay networks by configuring the devices in the way to the device 
that will be the host for the external port. This needs to be done, thinking 
that the devices on the external network are mostly heterogeneous and they must 
be configured automatically in a transparent way regardless of their 
characteristics and functional patterns.
My main concern is to decide which is the better way to do this. Can I go with 
the ML2 plugin and create a type driver and a mechanism driver to implement 
this virtual network extension as a new virtual network segment, or it would be 
better to implement it using the framework "Advanced Service Plugin" as a new 
type of service? In both possible solutions, we pretend to have an external 
agent to do the necessary configurations on the network devices.

Thank you,

Manuel Fernandes.






__
OpenStack Development Mailing 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] Nominating Julia Kreger for core reviewer

[Julia Kreger]

On Thu, Mar 24, 2016 at 3:08 PM, Jim Rollenhagen 
wrote:

> I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core.


I would like to thank the academy for... oh wait... wrong speech.

It is not often one gets to see a flood of positive messages from a
community, from the family that makes up Ironic.  And yes, I blushed.

Thank you everyone!

-Julia
__
OpenStack Development Mailing 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] [kolla][vote] deprecation of icehosue/juno/kilo branches

[Ryan Hallisey]

+1 for sure

-Ryan

- Original Message -
From: "Paul Bourke" 
To: openstack-dev@lists.openstack.org
Sent: Friday, March 25, 2016 11:43:06 AM
Subject: Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo 
branches

+1

On 25/03/16 15:36, Steven Dake (stdake) wrote:
> Hey folks,
>
> These branches are essentially unmaintained and we have completely given
> up on them.  That’s ok – they were paths of our development.  I didn't
> really want to branch them in the first place, but the community
> demanded it, so I delivered that :)
>
> Now that our architecture is fairly stable in liberty and mitaka, I
> think it makes sense to do the following
> 1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol
> 2. Ask infrastructure to remove the branches from git
>
> This is possible; I have just verified in openstack-infra.  I'd like a
> vote from the core review team.  If you would like to see the kilo
> branch stay, please note that, and if there is a majority on
> icehosue/juno but not kilo I'll make the appropriate arrangements with
> openstack-infra.
>
> I will leave voting open for 1 week until Saturday April 2nd.  I will
> close voting early if there is a majority vote.
>
> Regards
> -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
>

__
OpenStack Development Mailing 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] Which projects support wsgi / python3 in mitaka?

[Matthew Thode]

On 03/25/2016 09:54 AM, Matthew Thode wrote:
> I'm updating the packaging for openstack in preparation for the release
> and need some info to update correctly.  I'm specifically looking at the
> following services.
> 
> I don't know if any of these services support python3 fully as a service
> (liberty was kinda wishy washy on that).  Even if it supports python3,
> which version, 3.4 or 3.4 or 3.5 (or multiple).
> 
> keystone - probably - keystone/server/wsgi.py
> swift - don't think so
> glance - maybe? - glance/api/ and glance/registry/ seems to have some
> scripts, but not as simple as scrubber/registry/api.
> cinder - probably - cinder/wsgi/wsgi.py
> neutron - probably - neutron/server/wsgi_pecan.py
> nova - probably - both in nova/wsgi/
> heat - probably - three under heat/httpd/
> 
> Don't think docs are out yet (which would likely have some of this
> info), but any info you have around this would help.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Found the info around python3, just need confirmation on where to find
those wsgi scripts :P

Thanks for the link Ian.
https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projects

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

[openstack-dev] [election][TC] TC Candidacy

[Mike Perez]

Hi all!

I Mike Perez aka. thingee, am announcing my candidacy for a position in the
OpenStack Technical Committee. You can find my submitted candidacy which is
still under review here https://review.openstack.org/297748

I am employed by the OpenStack Foundation as a Developer Coordinator to help
bring focus/support to cross-project initiatives via the cross-project
specs, Def Core, The Product Working group, etc.

I feel the items below have enabled others across this project to strive for
quality. If you would all have me as a member of the Technical Committee, you
can help me to enable more quality work in OpenStack.

* I have been working in OpenStack since 2010. I spent a good amount of my time
  working on OpenStack in my free time before being paid full time to work on
  it. It has been an important part of my life, and rewarding to see what we
  have all achieved together.

* I was PTL for the Cinder project in the Kilo and Liberty releases.

* I led the effort in bringing third party continuous integration to the
  Cinder project for more than 60 different drivers. [1]
  * I removed 25 different storage drivers from Cinder to bring quality to the
project to ensure what was in the Kilo release would work for operators.
I did what I believed was right, regardless of whether it would cost me
re-election for PTL [2].
  * See epic thread on this once deadline happened [3]
  * In my conversations with other projects, this has enabled others to want to
follow the same effort.
- Ironic now has a road map for doing third-party CI. [4][5]

* I have attempted to help with diversity in our community, and I think it's
  great to have people in the committee that views this as a priority.
  - Helped lead our community to raise $17,403 for the Ada Initiative [6],
which was helping address gender-diversity with a focus in open source.
  - For the Vancouver summit, I helped bring in the ally skills workshops from
the Ada Initiative, so that our community can continue to be a welcoming
environment [4].
  - I have assisted Emily Hugenbruch with the OpenStack mentor program [7].
  - Based on some of the surveys the diversity working group has been doing,
OpenStack's tool chain of IRC, gerrit, and git was expressed as being
difficult to get started with. I started writing documentation to provide
step-by-step with screen shots to help improve our on-boarding experience
[8].

* I started the OpenStack Mailing List Digest, in order to enable others to
  keep up with the dev list on important information. [9][10]

* When Open Core was being discussed by the TC, numerous times I spoke to the
  TC about my disagreements with accepting projects in OpenStack's big tent if
  testing is only possible with a commercial entity. [11][12] I believe
  OpenStack service APIs should be based off an open source reference
  implementation that we're able to do integration tests with in gate. Anyone
  who begins to play with OpenStack should be able to run OpenStack with full
  features without a commercial entity/driver.
  - See my discussions with the TC in their meeting in raising quality and
being able to fully test projects we're considering in accepting in the big
tent [13].

* I have properly established the cross-project team [14] as well as the
  members that represent each OpenStack project [15].


As a TC member I want to bring focus in some areas:

1) Installation Documentation - I think all projects in the big tent should
   have installation documentation. In order for projects to gain adoption and
   gather better feedback, operators need to know how to install things. Today
   majority of projects in the big tent have no installation documentation,
   some which have existed for more than three years and still nothing. Where
   are these projects going? In addition I want to make all new projects
   entering the big tent come with clear documentation for installation. See
   the beginning discussions I'm starting here [16].

2) As expressed in the earlier point, there are some projects in the big tent
   that seem to have no clear direction and are lacking adoption after existing
   for years in the community. I'd like to work with these projects and see how
   we can move things forward to gain maturity, and some to be accepted in with
   Defcore and refstack. Otherwise I think these projects should be reevaluated
   in the value they're bringing to the big tent. This won't be easy, but it
   needs to be done to make sure community focus and resources we use from the
   Infra team is spent well. See the TC discussing CI resources VS project
   growth [17].

3) As expressed in the earlier point, Defcore plays a role in helping us define
   a set tests that will be ran against deployed OpenStack clouds interested in
   using the trademark. I'd like to continue working with both individual
   projects and Defcore/refstack in seeing if it's possible to make other
   

Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches

[Jeffrey Zhang]

+1

On Sat, Mar 26, 2016 at 12:07 AM, Ryan Hallisey  wrote:

> +1 for sure
>
> -Ryan
>
> - Original Message -
> From: "Paul Bourke" 
> To: openstack-dev@lists.openstack.org
> Sent: Friday, March 25, 2016 11:43:06 AM
> Subject: Re: [openstack-dev] [kolla][vote] deprecation of
> icehosue/juno/kilo branches
>
> +1
>
> On 25/03/16 15:36, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> > These branches are essentially unmaintained and we have completely given
> > up on them.  That’s ok – they were paths of our development.  I didn't
> > really want to branch them in the first place, but the community
> > demanded it, so I delivered that :)
> >
> > Now that our architecture is fairly stable in liberty and mitaka, I
> > think it makes sense to do the following
> > 1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol
> > 2. Ask infrastructure to remove the branches from git
> >
> > This is possible; I have just verified in openstack-infra.  I'd like a
> > vote from the core review team.  If you would like to see the kilo
> > branch stay, please note that, and if there is a majority on
> > icehosue/juno but not kilo I'll make the appropriate arrangements with
> > openstack-infra.
> >
> > I will leave voting open for 1 week until Saturday April 2nd.  I will
> > close voting early if there is a majority vote.
> >
> > Regards
> > -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
> >
>
> __
> OpenStack Development Mailing 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
>



-- 
Jeffrey Zhang
Blog: http://xcodest.me
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release][swift] Swift 2.7.0 released

[John Dickinson]

Today I'm happy to announce the OpenStack Swift 2.7.0 release.

Barring any major last-minute issues being discovered, our
contribution to the OpenStack Mitaka release includes the Swift 2.6.0
release and this 2.7.0 release.

This release includes some significant improvements that improve the
quality of life for both cluster operators and end users.

As always, you can upgrade to this version of Swift with zero end-user
downtime. I recommend that everyone upgrade.

- Tarball: https://tarballs.openstack.org/swift/swift-2.7.0.tar.gz
- Full Release Notes: https://github.com/openstack/swift/blob/master/CHANGELOG


Highlights from this release


- Fast-POST

"Fast-POST" is the mode where `object_post_as_copy` is set to
`False` in the proxy server config. This mode now allows for
fast, efficient updates of metadata without needing to fully
recopy the contents of the object. While the default still is
`object_post_as_copy` as True, the plan is to change the default
to False and then deprecate post-as-copy functionality in later
releases. Fast-POST now supports container-sync functionality.

The end result with this fast-POST update is that end-user POST
operations are much faster, and you can now use fast-POST with
container sync.

- Concurrent reads

Concurrent reads can significantly lower latency on reads as seen by
the end-user. If Swift is trying to read data off of a slow disk, it
can now opportunistically try another location in the cluster (before
the first operation times out). Swift will serve the request with the
first drive that responds, and the user sees lower time-to-first-byte
times when requesting data.

- An ops runbook

Swift's in-tree docs now include an operations runbook to help you do
the day-to-day of running your cluster. You can find the latest
version at http://swift.openstack.org/ops_runbook/ and a SuperUser
blog post introducing it at 
http://superuser.openstack.org/articles/help-improve-the-openstack-swift-operations-runbook.

- `handoffs_first` is not a more useful object replication mode

When a drive in the cluster fills up, the top priority is to add
capacity to the cluster and let the replication processes move data to
the newly available storage media. The `handoffs_first` replication
mode exists to prioritize this data movement. This feature has been
improved in this release to make sure that **all** data that needs to
leave the drive is prioritized before normal replication checks.

The end result of this feature update is that operators have a safer
and faster way to add new capacity to a full cluster and get the
cluster healthy again.

- Container sync improved

Container sync has been improved to perform a HEAD on the remote side
of the sync for each object being synced. If the object exists on the
remote side, container-sync will no longer transfer the object, thus
significantly lowering the network requirements to use the feature.

And these are just the highlights! I encourage you to read the full
release notes (linked at the top of this message) and upgrade today.

This release is the work of 52 code contributors, including 16 who
contributed for the first time.

Thank you to all who have contributed to Swift, via code or otherwise.
If you'd like to get more involved, join us in #openstack-swift on
freenode IRC.

--John






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

[openstack-dev] How does tempest read in the variables defined in tempest.conf?

[Danny Choi (dannchoi)]

Hi,

There are variables defined in the tempest.conf.  How does tempest read them 
and use them in the tests?

I'm trying to write scenario tests in multiple regions.

Under tempest.conf:


[identity]

Region = RegionOne


[compute]

image_ref = b6f85abb-c582-40e4-ad18-5a01431a6bfd

image_ref_alt = b6f85abb-c582-40e4-ad18-5a01431a6bfd


[network]

public_network_id = 51efe3a5-390f-4a40-a480-8aa41d704c69


I'm thinking to change these variables within the test on the fly to run test 
within that particular region

(region name, image id, public network id).


My question is what tempest variables uses these conf variables?


Is this the right approach or there is a better way to do it?


Thanks,

Danny
__
OpenStack Development Mailing 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] Which projects support wsgi / python3 in mitaka?

[Brant Knudson]

On Fri, Mar 25, 2016 at 9:54 AM, Matthew Thode 
wrote:

> I'm updating the packaging for openstack in preparation for the release
> and need some info to update correctly.  I'm specifically looking at the
> following services.
>
> I don't know if any of these services support python3 fully as a service
> (liberty was kinda wishy washy on that).  Even if it supports python3,
> which version, 3.4 or 3.4 or 3.5 (or multiple).
>
> keystone - probably - keystone/server/wsgi.py
>

For keystone you should use bin/keystone-wsgi-public and
bin/keystone-wsgi-admin as the wsgi entrypoints. The gate tests use
keystone running under mod_wsgi in apache httpd. We've also got a test in
keystone that uses uwsgi as the container.

Keystone doesn't support python 3 in M.

 - Brant
__
OpenStack Development Mailing 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] [kolla][vote] deprecation of icehosue/juno/kilo branches

[Sam Yaple]

+1

Sam Yaple

On Fri, Mar 25, 2016 at 4:52 PM, Michał Jastrzębski 
wrote:

> +1
>
> On 25 March 2016 at 11:36, Jeffrey Zhang  wrote:
> > +1
> >
> > On Sat, Mar 26, 2016 at 12:07 AM, Ryan Hallisey 
> wrote:
> >>
> >> +1 for sure
> >>
> >> -Ryan
> >>
> >> - Original Message -
> >> From: "Paul Bourke" 
> >> To: openstack-dev@lists.openstack.org
> >> Sent: Friday, March 25, 2016 11:43:06 AM
> >> Subject: Re: [openstack-dev] [kolla][vote] deprecation of
> >> icehosue/juno/kilo branches
> >>
> >> +1
> >>
> >> On 25/03/16 15:36, Steven Dake (stdake) wrote:
> >> > Hey folks,
> >> >
> >> > These branches are essentially unmaintained and we have completely
> given
> >> > up on them.  That’s ok – they were paths of our development.  I didn't
> >> > really want to branch them in the first place, but the community
> >> > demanded it, so I delivered that :)
> >> >
> >> > Now that our architecture is fairly stable in liberty and mitaka, I
> >> > think it makes sense to do the following
> >> > 1.. tag each of the above branches with icehosue-eol, juno-eol,
> kilo-eol
> >> > 2. Ask infrastructure to remove the branches from git
> >> >
> >> > This is possible; I have just verified in openstack-infra.  I'd like a
> >> > vote from the core review team.  If you would like to see the kilo
> >> > branch stay, please note that, and if there is a majority on
> >> > icehosue/juno but not kilo I'll make the appropriate arrangements with
> >> > openstack-infra.
> >> >
> >> > I will leave voting open for 1 week until Saturday April 2nd.  I will
> >> > close voting early if there is a majority vote.
> >> >
> >> > Regards
> >> > -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
> >> >
> >>
> >>
> __
> >> OpenStack Development Mailing 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
> >
> >
> >
> >
> > --
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] Non-candidacy

[Jay Pipes]

Hi all,

Thanks for all the fish. But it's time for me to move over and let some 
new voices contribute to the OpenStack Technical Committee.


I will continue to be a proponent for the viewpoint that OpenStack 
should be considered a toolkit of small, focused services and utilities, 
upon which great products can be built that expose cloud computing to 
ever-broader markets.


I'll just be a proponent of this view from outside the TC.

All the best, and thanks again for the opportunity to serve this past year.

-jay

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

[openstack-dev] [release][all][ptl] release liaisons for newton

[Doug Hellmann]

As we come to the close of the Mitaka cycle, and now that we have PTLs
for Newton in place, we need to establish our cross-project liaisons as
well. By default, the release liaison is the PTL and we can continue
with that assumption for Newton. If you would like to hand those duties
off to someone else, please update the wiki page appropriately [1].

We are making one small change in policy for liaisons this cycle. For
Mitaka we had a few projects with multiple deliverables designate a
separate person per deliverable. That has proven to be too much to keep
up with, so for Newton I would prefer that teams have a single release
liaison tracking all deliverables. That gives us the
single-point-of-contact we need for status updates. It's fine if you
want to divide up the work internally, of course, but I will expect the
liaison to either have up to date information or get it when asked.

Thanks,
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] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jeremy Stanley]

On 2016-03-25 16:33:44 -0400 (-0400), Jay Pipes wrote:
[...]
> What I'm proposing isn't using or needing a custom OpenStack
> deployment. There's nothing non-standard at all about the PCI or
> NFV stuff besides the hardware required to functionally test it.

What you _are_ talking about though is maintaining physical servers
in a data center running an OpenStack environment (and if you want
it participating in gating/preventing changes from merging you need
more than one environment so we don't completely shutdown
development when one of them collapses). This much has been a
challenge for the TripleO team, such that the jobs running for them
are still not voting on their changes.

> What we're talking about here is using the same upstream Infra
> Puppet modules, installed on a long-running server in a lab that
> can interface with upstream Gerrit, respond to new change events
> in the Gerrit stream, and trigger devstack-gate[-like] builds on
> some bare-metal gear.

It's possible I'm misunderstanding you... you're talking about
maintaining a deployment of OpenStack with specific hardware to be
able to run these jobs in, right? That's not as trivial an effort as
it sounds, and I'm skeptical "a couple of operators" is sufficient
to sustain such an endeavor.

> Is that something that is totally out of the question for the
> upstream Infra team to be a guide for?

We've stated in the past that we're willing to accept this level of
integration as long as our requirements for redundancy/uptime are
met. We mostly just don't want to see issues with the environment
block development for projects relying on it because it's the only
place those jobs can run, so multiple environments in different data
centers would be a necessity (right now our gating jobs are able to
run in any of 9 regions from 6 providers, which mitigates this
risk).
-- 
Jeremy Stanley

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

[openstack-dev] [openstac-dev][infra] High si/sys values via top in instances

[Bob Hansen]

Looking for some help to figure out what's going on here. I'm in the
process of creating a third party CI system for our project. I'm initially
trying to setup 6 manually created jenkins slaves using diskimage builder
and puppet to run gate jobs and will scale from there and eventually move
to nodepool.

I don't think this is specific to devstack-gate. I suspect it'll do this
with system activity that stresses the instance.

My setup is as follows:

Physical Servers(2): Intel 1 socket 12 core, 128gb RAM.
Openstack Liberty installed as a 3 node; 1 controller, 1 compute/network
(96gb RAM) , 2nd Compute (96gb RAM) as per the liberty installation guide.
Openstack controller, and compute ndoe guests, were created by hand using
libvirt on the respective physical server.
Using provider network, with linuxbridge.
Backing store for jenkins slaves/openstack liberty is the local file
system.
Jenkins slaves are built using puppet, images are built using diskimage
builder. The standard third party setup described in the CI documentation.
Jenkins slaves are 4 vcpu and 8gb of ram.
I have verified kvm acceleration is being used. All vm definitions are
using virtio for network and disk and virtio-pci is installed. All vms
using mode-passthrough in the cpu-model in the libvirt.xml describing it.

Trying to keep it simple as I learn the ropes...

All systems are using Kernel 3.19.0-56-generic #62~14.04.1-Ubuntu SMP on
Ubuntu 14.04.4 LTS (I've seen the same thing on early kernels and earlier
14.04 versions).

My issue is as follows,

If I create a single jenkins slave on a single compute node, the basic
setup time (we'll ignore tempest, but a similar thing happens) to run
devstack-gate is about roughly 20 minutes, sometimes less. As I scale the
number of jenkins slaves on the compute node, up to 3, the setup time
increases dramatically, the last run I did had it at nearly an hour.
Clearly something is wrong, as I have not over-comitted memory, nor ram on
either of the compute nodes.

What I'm finding is the CPU's are getting overwhelmed as I scale in the
jenkins slaves. Top will show sys/si percentages eating up the majority of
CPU, sometimes collectively they are taking up 70-80% of the cpu time. This
will drop to what's shown below when the system becomes idle.

When the systems are idle (after one run) this is a typical view of top,
mongodb is using 9.3% of the cpu, sys is at 9.8% and si at 5.2% of the
available cpu (Irix mode off). The compute node and the physical server do
not show this sort of load, they are typically in the 1-2% for sys, and 0,
for si when the slaves are idle, but will grow a bit when the slaves are
running the devstack-gate script.

top - 19:39:43 up 1 day, 39 min,  1 user,  load average: 0.65, 1.03, 1.59
Tasks: 145 total,   1 running, 144 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  9.8 sy,  0.0 ni, 77.9 id,  0.3 wa,  0.0 hi,  5.2 si,
6.5 st
KiB Mem:   8175872 total,  2620708 used,  164 free,   211212 buffers
KiB Swap:0 total,0 used,0 free.  1665764 cached Mem

  PID USER  PR  NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
 1402 mongodb   20   0  382064  48232  10912 S  9.3  0.6 162:25.72 mongod
18436 rabbitmq  20   0 2172776  54528   4072 S  4.2  0.7  20:41.26 beam.smp
20059 root  10 -10   20944420 48 S  2.9  0.0  26:54.20 monitor
20069 root  10 -10   21452432 48 S  2.6  0.0  25:45.48 monitor
28786 mysql 20   0 2375444 110308  11216 S  2.0  1.3  15:43.30 mysqld
 3731 jenkins   20   0 4113288 114320  21160 S  1.9  1.4  31:01.35 java
3 root  20   0   0  0  0 S  1.3  0.0  10:29.24
ksoftirqd/0


When the devstack-gate script is running this is typical. Again the compute
node as 0.6 for sy and 0.0 for si, when I copied this, similarly for the
physical server.

top - 19:45:02 up 1 day, 44 min,  1 user,  load average: 14.67, 12.20,
11.20
Tasks: 217 total,   5 running, 212 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.9 us, 43.5 sy,  0.0 ni,  5.2 id,  0.0 wa,  0.0 hi, 32.0 si,
0.4 st
KiB Mem:   8175872 total,  4970836 used,  3205036 free,   217968 buffers
KiB Swap:0 total,0 used,0 free.  1604240 cached Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
  687 jenkins   20   0   78420  21544   3296 R  45.7  0.3   4:17.87 ansible
  676 jenkins   20   0   78556  25556   7116 S  40.1  0.3   4:19.29 ansible
 1368 mongodb   20   0  382064  48508  10896 S  32.2  0.6 207:31.76 mongod
 5060 root  10 -10   20944420 48 S  14.1  0.0  12:04.99 monitor

Digging deeper with the various perf related tools, the best I can find for
a clue (used vmstat, looked at /proc/interrupts and mpstat, nothing in
logs), is that when idle mongo is doing this, which is driving up the sy
number. I have yet to figure out what may be driving the si number.

% time seconds  usecs/call callserrors syscall
-- --- --- - - 

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Jim Rollenhagen]

On Fri, Mar 25, 2016 at 03:20:30PM -0400, Doug Hellmann wrote:
> Excerpts from Jim Rollenhagen's message of 2016-03-25 10:45:30 -0700:
> > On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
> > > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> > > > On 24/03/16 08:01, Doug Hellmann wrote:
> > > > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35 +1000:
> > > > >> Hi Mike, and sorry I missed you on IRC to discuss this there. That 
> > > > >> said, I think it's great that you took this to the mailing list, 
> > > > >> especially seeing the conversation that has ensued.
> > > > >>
> > > > >> More inline ...
> > > > >>
> > > > >> On 24/03/16 01:06, Mike Perez wrote:
> > > > >>> Hey all,
> > > > >>>
> > > > >>> I've been talking to a variety of projects about lack of install 
> > > > >>> guides. This
> > > > >>> came from me not having a great experience with trying out projects 
> > > > >>> in the big
> > > > >>> tent.
> > > > >>>
> > > > >>> Projects like Manila have proposed install docs [1], but they were 
> > > > >>> rejected
> > > > >>> by the install docs team because it's not in defcore. One of 
> > > > >>> Manila's goals of
> > > > >>> getting these docs accepted is to apply for the operators tag
> > > > >>> ops:docs:install-guide [2] so that it helps their maturity level in 
> > > > >>> the project
> > > > >>> navigator [3].
> > > > >>>
> > > > >>> Adrian Otto expressed to me having the same issue for Magnum. I 
> > > > >>> think it's
> > > > >>> funny that a project that gets keynote time at the OpenStack 
> > > > >>> conference can't
> > > > >>> be in the install docs personally.
> > > > >>>
> > > > >>> As seen from the Manila review [1], the install docs team is 
> > > > >>> suggesting these
> > > > >>> to be put in their developer guide.
> > > > >>
> > > > >> As Steve pointed out, these now have solid plans to go in. That was 
> > > > >> because both projects opened a conversation with us and we worked 
> > > > >> with them over time to give them the docs they required.
> > > > >>
> > > > >>>
> > > > >>> I don't think this is a great idea. Mainly because they are for 
> > > > >>> developers,
> > > > >>> operators aren't going to be looking in there for install 
> > > > >>> information. Also the
> > > > >>> Developer doc page [4] even states "This page contains 
> > > > >>> documentation for Python
> > > > >>> developers, who work on OpenStack itself".
> > > > >>
> > > > >> I agree, but it's a great place to start. In fact, I've just merged 
> > > > >> a change to the Docs Contributor Guide (on the back of a previous 
> > > > >> mailing list conversation) that explicitly states this:
> > > > >>
> > > > >> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > > > 
> > > > > I think you're missing that most of us are disagreeing that it is
> > > > > a good place to start. It's fine to have the docs in a repository
> > > > > managed by the project team. It's not good at all to publish them
> > > > > under docs.o.o/developer because they are not for developers, and
> > > > > so it's confusing. This is why we ended up with a different place
> > > > > for release notes to be published, instead of just adding reno to
> > > > > the existing developer documentation build, for example.
> > > > > 
> > > > 
> > > > All docs need to be drafted somewhere. I don't care where that is, but 
> > > > make the suggestion of /developer because at least it's accessible 
> > > > there, and also because it's managed in the project's own repo. If you 
> > > > want to create a different place, or rename /developer to be more 
> > > > inclusive, I think that's a great idea.
> > > 
> > > I think we'll want to add a new location, or publish to a similar
> > > location to the existing install guide. I found, for example
> > > http://docs.openstack.org/mitaka/install-guide-ubuntu/
> > > 
> > > If we take ironic as the example, and assume all OS-types would be
> > > covered in one manual, we could make that:
> > > 
> > > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> > > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> > > (3) http://docs.openstack.org/install-guide/ironic/
> > > (4) http://docs.openstack.org/ironic/install-guide/
> > > 
> > > I like options 3 and 4. To keep things simple for the project teams,
> > > I think we want to skip including the release series in the base
> > > URL.  As the instructions change, projects may need to create
> > > separate sub-sections of their guide for each series, but they
> > > should be able to do that without having to set up separate publishing
> > > locations and jobs.
> > > 
> > > Another benefit of options 3 and 4 is that as the ironic team
> > > produces other guides, those can go under a consistent URL that
> > > makes it relatively simple to set up a generic publishing job for
> > > all projects. Option 4 does have the benefit of making it easy to
> > > have a page at 

Re: [openstack-dev] [nova] The same SRIOV / NFV CI failures missed a regression, why?

[Jay Pipes]

On 03/24/2016 09:35 AM, Matt Riedemann wrote:

We have another mitaka-rc-potential bug [1] due to a regression when
detaching SR-IOV interfaces in the libvirt driver.

There were two NFV CIs that ran on the original change [2].

Both failed with the same devstack setup error [3][4].

So it sucks that we have a regression, it sucks that no one watched for
those CI results before approving the change, and it really sucks in
this case since it was specifically reported from mellanox for sriov
which failed in [4]. But it happens.

What I'd like to know is, have the CI problems been fixed? There is a
change up to fix the regression [5] and this time the Mellanox CI check
is passing [6]. The Intel NFV CI hasn't reported, but with the mellanox
one also testing the suspend scenario, it's probably good enough.


From the commit message of the original patch that introduced the 
regression:


"This fix was tested on a real environment containing the above type of 
VMs. test_driver.test_detach_sriov_ports was slightly modified so that 
the VIF from which data is sent to _detach_pci_devices will contain the 
correct SRIOV values (pci_slot, vlan and hw_veb VIF type)"


I'm not sure if the above statement could ever have been true 
considering the AttributeError that occurred in the bug...


In any case, I think that it's pretty clear that the CI systems for NFV 
and PCI have been less than reliable at functionally testing the PCI and 
NFV-specific functionality in Nova.


This isn't trying to put down the people that work on those systems -- I 
know first hand that it can be difficult to build and maintain CI 
systems that report in to upstream, and I appreciate the effort that 
goes into this.


But, going forward, I think we need to do something as a concerned 
community.


How about this for a proposal?

1) We establish a joint lab environment that contains heterogeneous 
hardware to which all interested hardware vendors must provide hardware.


2) The OpenStack Foundation and the hardware vendors each foot some 
portion of the bill to hire 2 or more systems administrators to maintain 
this lab environment.


3) The upstream Infrastructure team works with the hired system 
administrators to create a single CI system that can spawn functional 
test jobs on the lab hardware and report results back to upstream Gerrit


Given the will to do this, I think the benefits of more trusted testing 
results for the PCI and SR-IOV/NFV areas would more than make up for the 
cost.


Best,
-jay

__
OpenStack Development Mailing 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Andreas Jaeger]

On 03/25/2016 08:20 PM, Doug Hellmann wrote:
> Excerpts from Jim Rollenhagen's message of 2016-03-25 10:45:30 -0700:
>> > On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
>>> > > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
 > > > On 24/03/16 08:01, Doug Hellmann wrote:
> > > > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35 
> > > > > +1000:
>> > > > >> Hi Mike, and sorry I missed you on IRC to discuss this there. 
>> > > > >> That said, I think it's great that you took this to the mailing 
>> > > > >> list, especially seeing the conversation that has ensued.
>> > > > >>
>> > > > >> More inline ...
>> > > > >>
>> > > > >> On 24/03/16 01:06, Mike Perez wrote:
>>> > > > >>> Hey all,
>>> > > > >>>
>>> > > > >>> I've been talking to a variety of projects about lack of 
>>> > > > >>> install guides. This
>>> > > > >>> came from me not having a great experience with trying out 
>>> > > > >>> projects in the big
>>> > > > >>> tent.
>>> > > > >>>
>>> > > > >>> Projects like Manila have proposed install docs [1], but they 
>>> > > > >>> were rejected
>>> > > > >>> by the install docs team because it's not in defcore. One of 
>>> > > > >>> Manila's goals of
>>> > > > >>> getting these docs accepted is to apply for the operators tag
>>> > > > >>> ops:docs:install-guide [2] so that it helps their maturity 
>>> > > > >>> level in the project
>>> > > > >>> navigator [3].
>>> > > > >>>
>>> > > > >>> Adrian Otto expressed to me having the same issue for Magnum. 
>>> > > > >>> I think it's
>>> > > > >>> funny that a project that gets keynote time at the OpenStack 
>>> > > > >>> conference can't
>>> > > > >>> be in the install docs personally.
>>> > > > >>>
>>> > > > >>> As seen from the Manila review [1], the install docs team is 
>>> > > > >>> suggesting these
>>> > > > >>> to be put in their developer guide.
>> > > > >>
>> > > > >> As Steve pointed out, these now have solid plans to go in. That 
>> > > > >> was because both projects opened a conversation with us and we 
>> > > > >> worked with them over time to give them the docs they required.
>> > > > >>
>>> > > > >>>
>>> > > > >>> I don't think this is a great idea. Mainly because they are 
>>> > > > >>> for developers,
>>> > > > >>> operators aren't going to be looking in there for install 
>>> > > > >>> information. Also the
>>> > > > >>> Developer doc page [4] even states "This page contains 
>>> > > > >>> documentation for Python
>>> > > > >>> developers, who work on OpenStack itself".
>> > > > >>
>> > > > >> I agree, but it's a great place to start. In fact, I've just 
>> > > > >> merged a change to the Docs Contributor Guide (on the back of a 
>> > > > >> previous mailing list conversation) that explicitly states this:
>> > > > >>
>> > > > >> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > > > 
> > > > > I think you're missing that most of us are disagreeing that it is
> > > > > a good place to start. It's fine to have the docs in a repository
> > > > > managed by the project team. It's not good at all to publish them
> > > > > under docs.o.o/developer because they are not for developers, and
> > > > > so it's confusing. This is why we ended up with a different place
> > > > > for release notes to be published, instead of just adding reno to
> > > > > the existing developer documentation build, for example.
> > > > > 
 > > > 
 > > > All docs need to be drafted somewhere. I don't care where that is, 
 > > > but make the suggestion of /developer because at least it's 
 > > > accessible there, and also because it's managed in the project's own 
 > > > repo. If you want to create a different place, or rename /developer 
 > > > to be more inclusive, I think that's a great idea.
>>> > > 
>>> > > I think we'll want to add a new location, or publish to a similar
>>> > > location to the existing install guide. I found, for example
>>> > > http://docs.openstack.org/mitaka/install-guide-ubuntu/
>>> > > 
>>> > > If we take ironic as the example, and assume all OS-types would be
>>> > > covered in one manual, we could make that:
>>> > > 
>>> > > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
>>> > > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
>>> > > (3) http://docs.openstack.org/install-guide/ironic/
>>> > > (4) http://docs.openstack.org/ironic/install-guide/
>>> > > 
>>> > > I like options 3 and 4. To keep things simple for the project teams,
>>> > > I think we want to skip including the release series in the base
>>> > > URL.  As the instructions change, projects may need to create
>>> > > separate sub-sections of their guide for each series, but they
>>> > > should be able to do that 

Re: [openstack-dev] [release][all][ptl] release liaisons for newton

[Doug Hellmann]

> On Mar 25, 2016, at 3:35 PM, Doug Hellmann  wrote:
> 
> As we come to the close of the Mitaka cycle, and now that we have PTLs
> for Newton in place, we need to establish our cross-project liaisons as
> well. By default, the release liaison is the PTL and we can continue
> with that assumption for Newton. If you would like to hand those duties
> off to someone else, please update the wiki page appropriately [1].
> 
> We are making one small change in policy for liaisons this cycle. For
> Mitaka we had a few projects with multiple deliverables designate a
> separate person per deliverable. That has proven to be too much to keep
> up with, so for Newton I would prefer that teams have a single release
> liaison tracking all deliverables. That gives us the
> single-point-of-contact we need for status updates. It's fine if you
> want to divide up the work internally, of course, but I will expect the
> liaison to either have up to date information or get it when asked.
> 
> Thanks,
> Doug

Oops, missed adding the link to the wiki page:

https://wiki.openstack.org/wiki/CrossProjectLiaisons


__
OpenStack Development Mailing 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] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jeremy Stanley]

On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
[...]
> 3) The upstream Infrastructure team works with the hired system
> administrators to create a single CI system that can spawn
> functional test jobs on the lab hardware and report results back
> to upstream Gerrit
[...]

This bit is something the TripleO team has struggled to accomplish
over the past several years (running a custom OpenStack deployment
tied directly into our CI), so at a minimum we'd want to know how
the proposed implementation would succeed in ways that they've so
far found a significant challenge even with a larger sysadmin team
than you estimate being required.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

[Jay Pipes]

On 03/25/2016 04:08 PM, Jeremy Stanley wrote:

On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
[...]

3) The upstream Infrastructure team works with the hired system
administrators to create a single CI system that can spawn
functional test jobs on the lab hardware and report results back
to upstream Gerrit

[...]

This bit is something the TripleO team has struggled to accomplish
over the past several years (running a custom OpenStack deployment
tied directly into our CI), so at a minimum we'd want to know how
the proposed implementation would succeed in ways that they've so
far found a significant challenge even with a larger sysadmin team
than you estimate being required.


What I'm proposing isn't using or needing a custom OpenStack deployment. 
There's nothing non-standard at all about the PCI or NFV stuff besides 
the hardware required to functionally test it.


What we're talking about here is using the same upstream Infra Puppet 
modules, installed on a long-running server in a lab that can interface 
with upstream Gerrit, respond to new change events in the Gerrit stream, 
and trigger devstack-gate[-like] builds on some bare-metal gear.


Is that something that is totally out of the question for the upstream 
Infra team to be a guide for?


-jay

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

[openstack-dev] Release countdown for week R-1, Mar 27 - Apr 1

[Doug Hellmann]

This is our final week before the release is done.

Focus
-

Project teams following the cycle-with-milestone model should be
testing their release candidates and fixing release-critical bugs.
We have had some second and third release candidates, so we hope
things settle and those can become final releases.

Project teams following the cycle-with-intermediary model should
ensure they have at least one Mitaka release, and determine whether
they will need another release before the end of the Mitaka cycle.

All project teams should be working on release-critical bugs.

General Notes
-

The global requirements list is still frozen, but we expect it to
open soon (we'll send another announcement of that). If you need
to change a dependency, for example to include a bug fix in one of
our libraries or an upstream library, please provide enough detail
in the change request to allow the requirements review team to
evaluate the change.

The master branches for all projects following cycle-with-milestone
are open for Newton development work. Review teams are still likely
to be working on bug fixes for Mitaka, so be patient if you start
posting feature work.

Release Actions
---

There are still a few cycle-with-intermediary projects without a
clear indication if they have cut their final release:

bifrost
magnum
python-searchlightclient
senlin-dashboard
solum-infra-guestagent
os-win
cloudkitty
tacker

Please contact the release team, or submit a release request to the
releases repository, to address these missing releases as soon as
possible. Do NOT wait for the end of the week (submit a request by
Wednesday or Thursday at the latest).

We will not be doing any more intermediary releases after Thursday
unless the release is a critical bug fix to an existing release,
so it is better to go ahead and release something to give consumers
a chance to test. After Mar 31 feature releases will be counted as
part of the Newton cycle.

The release team will have reduced availability between R-1 and the
summit due to travel. Please use the mailing list to contact us and
to ensure one of us sees your question include "[release]" in the
subject line.

Important Dates
---

Final release candidates: Mar 31
Mitaka final release: Apr 7

Mitaka release schedule: http://releases.openstack.org/mitaka/schedule.html

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

[openstack-dev] [nova] Bug for image_cache_manager refactoring

[Augustina Ragwitz]

I came across a bug filed back in August [1] that brought up a potential
issue with the image_cache_manager in that the loop for building the
BlockDeviceMappingList has the potential to generate enough messages to
take down nova-conductor. There is a TODO comment in the code that
indicates it needs to be refactored. It looks like there was a fix proposed
that was recently abandoned and the bug has now been relabeled as "New".

Currently there is a comment that we should reassess this bug. Should I go
ahead and mark this bug as confirmed to get it into the Triage pipeline? To
me it seems legit, but maybe someone with more context has a different
opinion?

[1] https://bugs.launchpad.net/nova/+bug/1484847

---
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy
__
OpenStack Development Mailing 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] [murano] Does anybody need OAuth1 API in keystone?

[Adam Young]

On 03/25/2016 08:44 AM, Alexander Tivelkov wrote:

Hi Alexander,

We - the murano team (so adding [murano] to subj) - are planning to 
utilise keystone's OAuth flow in Newton timeframe.


Our use cases require to have ability to delegate some of user's 
privileges o various kinds of external (i.e. non-openstack) apps or 
services, so they may interact with Murano API on behalf of that user.


A real-life example is a Cloud Foundry integration: we have a service 
which acts as a Cloud Foundry Service Broker [1]: it exposes a 
CloudFoundry-compatible APIs but under the hood implements them as 
calls to Murano APIs. So, it needs to authenticate with Keystone using 
some valid credentials. Right now we use regular user's name and 
password for that, but this approach is not perfect, since these 
services may be controlled by third-parties, so the users may not 
trust them - so, this is the exact use case for the OAuth as a standard.


Another example of highly demanded use case for murano are custom 
murano-powered CI/CD pipelines: in such deployments a build server may 
need to generate murano applications, form murano packages, upload it 
to package repository (glance/glare) and then deploy that package 
within an appropriate murano environment. This case also requires this 
buildserver to call glare and murano APIs on behalf of the user owning 
the job. We have such deployments right now, but they also are 
statically configured with the usernames and passwords of some service 
users, and that's not right.


So, we are looking forward for OAuth indeed.

I did some research with the current implementation, it obviously has 
some issues (including the security ones), but I strongly believe that 
it should be fixed and improved, not dropped (after all, silently 
dropping a part of public api should never be an option in openstack: 
once public - always public).
If you need my help or feedback on use-cases and found issues - please 
let me know, I'll be happy to help.




This is good to know, and exactly what the API was designed for.  We are 
looking to unify the implementation with how we do Trusts and Role 
Assignments, but we will not be changing the semantics.  We just were 
hoping to avoid the work for OAUTH if it was not being used.




[1] http://docs.cloudfoundry.org/services/api.html


On Thu, Mar 17, 2016 at 1:05 PM Alexander Makarov 
> wrote:


Hi!

I'm working on unifying all the models that store actor access
rights to the resources [0],
and now I'm wondering if we can just drop current OAuth1
implementation [1].
It's definitely not perfect and require considerable effort to
bring it in good shape so the question is if the feature worth the
attention?

​[0]​
https://blueprints.launchpad.net/keystone/+spec/unified-delegation
[1] https://github.com/openstack/keystone/tree/master/keystone/oauth1

-- 
Kind Regards,

Alexander Makarov,
Senior Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
__
OpenStack Development Mailing 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,
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] [magnum] Enhance Mesos bay to a DCOS bay

[Jay Lau]

Yes, that's exactly what I want to do, adding dcos cli and also add Chronos
to Mesos Bay to make it can handle both long running services and batch
jobs.

Thanks,

On Fri, Mar 25, 2016 at 5:25 PM, Michal Rostecki 
wrote:

> On 03/25/2016 07:57 AM, Jay Lau wrote:
>
>> Hi Magnum,
>>
>> The current mesos bay only include mesos and marathon, it is better to
>> enhance the mesos bay have more components and finally enhance it to a
>> DCOS which focus on container service based on mesos.
>>
>> For more detail, please refer to
>>
>> https://docs.mesosphere.com/getting-started/installing/installing-enterprise-edition/
>>
>> The mesosphere now has a template on AWS which can help customer deploy
>> a DCOS on AWS, it would be great if Magnum can also support it based on
>> OpenStack.
>>
>> I filed a bp here
>> https://blueprints.launchpad.net/magnum/+spec/mesos-dcos , please show
>> your comments if any.
>>
>> --
>> Thanks,
>>
>> Jay Lau (Guangya Liu)
>>
>>
> Sorry if I'm missing something, but isn't DCOS a closed source software?
>
> However, the "DCOS cli"[1] seems to be working perfectly with Marathon and
> Mesos installed by any way if you configure it well. I think that the thing
> which can be done in Magnum is to make the experience with "DOCS" tools as
> easy as possible by using open source components from Mesosphere.
>
> Cheers,
> Michal
>
> [1] https://github.com/mesosphere/dcos-cli
>
> __
> OpenStack Development Mailing 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,

Jay Lau (Guangya Liu)
__
OpenStack Development Mailing 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-Dev][Manila] BP https://blueprints.launchpad.net/manila/+spec/access-group

[Adam Young]

On 03/25/2016 08:43 AM, nidhi.h...@wipro.com wrote:


Hi All,

A gentle reminder..

Could you please share your thoughts on the approach proposed here ..

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

Thanks

Nidhi

*From:* Nidhi Mittal Hada (Product Engineering Service)
*Sent:* Wednesday, March 09, 2016 2:22 PM
*To:* 'OpenStack Development Mailing List (not for usage questions)' 

*Cc:* 'bswa...@netapp.com' ; 'Ben Swartzlander' 

*Subject:* RE: [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-groups


Hi All,

This is just a gentle reminder to the previous mail ..

PFA is revised doc.

Same is pasted here also.

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

Kindly share your thoughts on this..

Thanks

Nidhi



Nidhi,


It seems like this is the resource level access control that people have 
been asking for in many projects.  A few thoughts:


Deny rules are tricky.  I would prefer an access control approach that 
denied all by default, and then only allowed explicit adds.



The idea of access groups is much like the roles we have in Keystone.  
With domain specific roles, we have the potential to do some of this, 
but at a courser level.  I wonder if we could unify the approach, such 
that the roles are managed in Keystone, and then could apply to things 
other than items in Manila?


In general, I do not like to have individual users in access lists, 
especially when they might be the only person that can clean up a 
resource, and then they leave.  That means things fall back on "Admin".  
Ideally, all access would be controlled via groups membership.



What you are writing is really similar to the oslo-policy enforcement 
rules.  Are you planning on using Oslo to enforce?


Sorry for jumping in to the middle here, but you did ask for feedback!


*From:* Nidhi Mittal Hada (Product Engineering Service)
*Sent:* Friday, February 26, 2016 3:22 PM
*To:* 'OpenStack Development Mailing List (not for usage questions)' 
>
*Cc:* 'bswa...@netapp.com' >; 'Ben Swartzlander' >
*Subject:* [OpenStack-Dev][Manila] BP 
https://blueprints.launchpad.net/manila/+spec/access-groups


Hi Manila Team,

I am working on

https://blueprints.launchpad.net/manila/+spec/access-groups

For this I have created initial document as attached with the mail.

It contains DB CLI REST API related changes.

Could you please have a look and share your opinion.

Kindly let me know, if there is some understanding gap,

or something I have missed to document or

share your comments in general to make it better.

*Thank you.*

*Nidhi Mittal Hada*

*Architect | PES / COE*– *Kolkata India*

*Wipro Limited*

*M*+91 74 3910 9883 | *O* +91 33 3095 4767 | *VOIP* +91 33 3095 4767

The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately and destroy all copies of this message and any 
attachments. WARNING: Computer viruses can be transmitted via email. 
The recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage 
caused by any virus transmitted by this email. www.wipro.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


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

[openstack-dev] [release][packaging] Mitaka packaged on gentoo

[Matthew Thode]

I've finished packaging mitaka on Gentoo, won't be marked stable for
about a month.  The version packaged is based off of the stable/mitaka
branch (noted by the version being 2016.1.).  I haven't found where
an upgrade guide is being worked on (if anywhere), so that would help in
testing if anyone knows where it is.

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

[openstack-dev] OpenStack Developer Mailing List Digest March 19-25

[Mike Perez]

HTML version: 
http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/

SuccessBot Says
===
* redrobot: The Barbican API guides is now being published. [1]
* jroll: ironic 5.1.0 released as the basis for stable/mitaka.
* ttx: All RC1s up for milestones-driven projects.
* zara: storyboard.openstack.org sends emails now!
* noggin143: my first bays running on CERN production cloud with Magnum.
* sdague: Grenade upgraded to testing stable/liberty -> stable/mitaka and
  stable/mitaka -> master.
* Tell us yours via IRC with a message “#success [insert success]”.
* All: https://wiki.openstack.org/wiki/Successes


PTL Election Conclusion and Results
===
* Results are in, congrats to everyone! [2]
* Appointed PTLs by the TC for leaderless Projects [3]:
  - EC-API: Alex Andrelevine
  - Stable Branch Maintenance: Tony Breeds
  - Winstackers: Claudiu Belu
Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html


Candidate Proposals for Technical Committee Positions Are Now Open
===
* Important dates:
  - Nominations open: 2016-03-25 00:00 UTC
  - Nominations close: 2016-03-31 23:59 UTC
  - Election open: 2015-04-01 00:00 UTC
  - Election close: 2015-04-07 23:59 UTC
* More details on the election [4]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090421.html


Release countdown for week R-1, Mar 27 - Apr 1
==
* Focus:
  - Project teams following the cycle-with-milestone model should be testing
their release Candidates.
  - Project teams following the cycle-with-intermediary model should have at
least one Mitaka release and determine if another release is needed before
the end of the Mitaka cycle.
  - All projects should be working on release-critical-bugs.
* General Notes:
  - Global-requirements list is still frozen.
  - If you need to change a dependency for release-critical-bug fix, provide
enough details in the change request.
  - Master branches for all projects following cycle-with-milestone are open
for Newton development work.
* Release Actions:
  - Projects following cycle-with-intermediary without clear indication of
cutting their final release:
+ bifrost
+ magnum
+ python-searchlightclient
+ senlin-dashboard
+ solum-infra-guestagent
+ os-win
+ cloudkitty
+ tacker
  - These projects should contact the release team or submit a release request
to the releases repository as soon as possible. Please submit a request by
Wednesday or Thursday at the latest.
+ After March 31st, feature releases will be counted as part of Newton
  cycle.
  - The release team will have reduced availability between R1 and summit due
to travel. Use the dev mailing list to contact the team and include
"[release]" in the subject.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089701.html


Bots and Their Effects: Gerrit, IRC, other
==
* Bots are very handy for doing repetitive tasks.
* These require require permissions to execute certain actions, require
  maintenance to ensure they operate as expected and do create output which is
  music to some and noise to others
* From an infra meeting [5], this is what has been raised so far:
  - Permissions: having a bot on gerrit with +2 +A is something we would
like to avoid
  - "unsanctioned" bots (bots not in infra config files) in channels
shared by multiple teams (meeting channels, the -dev channel)
  - Forming a dependence on bots and expecting infra to maintain them ex
post facto (example: bot soren maintained until soren didn't)
  - Causing irritation for others due to the presence of an echoing bot
which eventually infra will be asked or expected to mediate
  - Duplication of features, both meetbot and purplebot log channels and host
the archives in different locations
  - Canonical bot doesn't get maintained
* It's possible bots that infra currently maintains have features that folks
  are unaware of.
* Bots that +2 reviews and approve them can be a problem when taking into
  account of schedules, outages, gate issues, etc.
* The Success bot for example is and added feature that takes advantage of the
  already existing status bot.
* What are the reasons that people end up writing their own bots instead of
  contributing to the existing infrastructure bots when applicable?
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90262


Semantic Version On Master Branches After RC

* The release team assumes three options someone would choose when installing
  things:
  - Tagged versions from any branch.
+ Clear, and always produces deployments that are reproduceable, with
  versions 

[openstack-dev] [Rally][Product] Rally roadmap slide updated

[Arkady_Kanevsky]

Team,
I had updated the slide based on Rally team feedback
https://docs.google.com/presentation/d/1GmJ2iaDfLkQda_TGxHpFEEIQgrm_scvDsvep_wXVeUQ/edit#slide=id.g84f9afb4d_0_0

Thanks,
Arkady
__
OpenStack Development Mailing 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][dvr]Why keep SNAT centralized and DNAT distributed?

[Zhi Chang]

hi all.


I have some questions about NAT in DVR. 


In Neutron, we provide two NAT types. One is SNAT, we can associate a 
floating ip to router so that all vms attached this router can connect external 
network. The other NAT types is DNAT, we can connect a vm which associated 
floating ip from external network.


 Question A, Why keep SNAT centralized? We put the SNAT namespace in 
compute node which running DVR l3 agent, don't we?


 Question B, Why keep DNAT distributed? I think we can keep snat namespace 
and fip namespace in one node. Why not keep DNAT and SNAT together? 




Thanks
Zhi CHang__
OpenStack Development Mailing 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2016-03-25 10:45:30 -0700:
> On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
> > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> > > On 24/03/16 08:01, Doug Hellmann wrote:
> > > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35 +1000:
> > > >> Hi Mike, and sorry I missed you on IRC to discuss this there. That 
> > > >> said, I think it's great that you took this to the mailing list, 
> > > >> especially seeing the conversation that has ensued.
> > > >>
> > > >> More inline ...
> > > >>
> > > >> On 24/03/16 01:06, Mike Perez wrote:
> > > >>> Hey all,
> > > >>>
> > > >>> I've been talking to a variety of projects about lack of install 
> > > >>> guides. This
> > > >>> came from me not having a great experience with trying out projects 
> > > >>> in the big
> > > >>> tent.
> > > >>>
> > > >>> Projects like Manila have proposed install docs [1], but they were 
> > > >>> rejected
> > > >>> by the install docs team because it's not in defcore. One of Manila's 
> > > >>> goals of
> > > >>> getting these docs accepted is to apply for the operators tag
> > > >>> ops:docs:install-guide [2] so that it helps their maturity level in 
> > > >>> the project
> > > >>> navigator [3].
> > > >>>
> > > >>> Adrian Otto expressed to me having the same issue for Magnum. I think 
> > > >>> it's
> > > >>> funny that a project that gets keynote time at the OpenStack 
> > > >>> conference can't
> > > >>> be in the install docs personally.
> > > >>>
> > > >>> As seen from the Manila review [1], the install docs team is 
> > > >>> suggesting these
> > > >>> to be put in their developer guide.
> > > >>
> > > >> As Steve pointed out, these now have solid plans to go in. That was 
> > > >> because both projects opened a conversation with us and we worked with 
> > > >> them over time to give them the docs they required.
> > > >>
> > > >>>
> > > >>> I don't think this is a great idea. Mainly because they are for 
> > > >>> developers,
> > > >>> operators aren't going to be looking in there for install 
> > > >>> information. Also the
> > > >>> Developer doc page [4] even states "This page contains documentation 
> > > >>> for Python
> > > >>> developers, who work on OpenStack itself".
> > > >>
> > > >> I agree, but it's a great place to start. In fact, I've just merged a 
> > > >> change to the Docs Contributor Guide (on the back of a previous 
> > > >> mailing list conversation) that explicitly states this:
> > > >>
> > > >> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > > 
> > > > I think you're missing that most of us are disagreeing that it is
> > > > a good place to start. It's fine to have the docs in a repository
> > > > managed by the project team. It's not good at all to publish them
> > > > under docs.o.o/developer because they are not for developers, and
> > > > so it's confusing. This is why we ended up with a different place
> > > > for release notes to be published, instead of just adding reno to
> > > > the existing developer documentation build, for example.
> > > > 
> > > 
> > > All docs need to be drafted somewhere. I don't care where that is, but 
> > > make the suggestion of /developer because at least it's accessible there, 
> > > and also because it's managed in the project's own repo. If you want to 
> > > create a different place, or rename /developer to be more inclusive, I 
> > > think that's a great idea.
> > 
> > I think we'll want to add a new location, or publish to a similar
> > location to the existing install guide. I found, for example
> > http://docs.openstack.org/mitaka/install-guide-ubuntu/
> > 
> > If we take ironic as the example, and assume all OS-types would be
> > covered in one manual, we could make that:
> > 
> > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> > (3) http://docs.openstack.org/install-guide/ironic/
> > (4) http://docs.openstack.org/ironic/install-guide/
> > 
> > I like options 3 and 4. To keep things simple for the project teams,
> > I think we want to skip including the release series in the base
> > URL.  As the instructions change, projects may need to create
> > separate sub-sections of their guide for each series, but they
> > should be able to do that without having to set up separate publishing
> > locations and jobs.
> > 
> > Another benefit of options 3 and 4 is that as the ironic team
> > produces other guides, those can go under a consistent URL that
> > makes it relatively simple to set up a generic publishing job for
> > all projects. Option 4 does have the benefit of making it easy to
> > have a page at http://docs.openstack.org/ironic/ linking to all of
> > the guides the ironic team has published.
> > 
> > Thoughts?
> 
> I also like 3 and 4. I like 3 because it's a similar structure to the
> developer docs, however I do like 4 giving us the option to publish
> other 

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Doug Hellmann]

Excerpts from Mike Perez's message of 2016-03-25 11:32:58 -0700:
> > On Mar 25, 2016, at 06:10, Doug Hellmann  wrote:
> > 
> > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> >> 
> >> All docs need to be drafted somewhere. I don't care where that is, but 
> >> make the suggestion of /developer because at least it's accessible there, 
> >> and also because it's managed in the project's own repo. If you want to 
> >> create a different place, or rename /developer to be more inclusive, I 
> >> think that's a great idea.
> > 
> > I think we'll want to add a new location, or publish to a similar
> > location to the existing install guide. I found, for example
> > http://docs.openstack.org/mitaka/install-guide-ubuntu/
> > 
> > If we take ironic as the example, and assume all OS-types would be
> > covered in one manual, we could make that:
> > 
> > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> > (3) http://docs.openstack.org/install-guide/ironic/
> > (4) http://docs.openstack.org/ironic/install-guide/
> 
> I like option 3.
> 
> All install guides would be discoverable at /install-guides that are rendered 
> docs from individual projects' repos.
> 
> Regardless of what direction people would like to go here, I will be happy to 
> spearhead this from a cross-project perspective.

Thanks, Mike, that would be good. I'm happy to help out, too.

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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2016-03-25 20:30:01 +0100:
> On 03/25/2016 08:20 PM, Doug Hellmann wrote:
> > Excerpts from Jim Rollenhagen's message of 2016-03-25 10:45:30 -0700:
> >> > On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
> >>> > > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
>  > > > On 24/03/16 08:01, Doug Hellmann wrote:
> > > > > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35 
> > > > > > +1000:
> >> > > > >> Hi Mike, and sorry I missed you on IRC to discuss this there. 
> >> > > > >> That said, I think it's great that you took this to the 
> >> > > > >> mailing list, especially seeing the conversation that has 
> >> > > > >> ensued.
> >> > > > >>
> >> > > > >> More inline ...
> >> > > > >>
> >> > > > >> On 24/03/16 01:06, Mike Perez wrote:
> >>> > > > >>> Hey all,
> >>> > > > >>>
> >>> > > > >>> I've been talking to a variety of projects about lack of 
> >>> > > > >>> install guides. This
> >>> > > > >>> came from me not having a great experience with trying out 
> >>> > > > >>> projects in the big
> >>> > > > >>> tent.
> >>> > > > >>>
> >>> > > > >>> Projects like Manila have proposed install docs [1], but 
> >>> > > > >>> they were rejected
> >>> > > > >>> by the install docs team because it's not in defcore. One 
> >>> > > > >>> of Manila's goals of
> >>> > > > >>> getting these docs accepted is to apply for the operators 
> >>> > > > >>> tag
> >>> > > > >>> ops:docs:install-guide [2] so that it helps their maturity 
> >>> > > > >>> level in the project
> >>> > > > >>> navigator [3].
> >>> > > > >>>
> >>> > > > >>> Adrian Otto expressed to me having the same issue for 
> >>> > > > >>> Magnum. I think it's
> >>> > > > >>> funny that a project that gets keynote time at the 
> >>> > > > >>> OpenStack conference can't
> >>> > > > >>> be in the install docs personally.
> >>> > > > >>>
> >>> > > > >>> As seen from the Manila review [1], the install docs team 
> >>> > > > >>> is suggesting these
> >>> > > > >>> to be put in their developer guide.
> >> > > > >>
> >> > > > >> As Steve pointed out, these now have solid plans to go in. 
> >> > > > >> That was because both projects opened a conversation with us 
> >> > > > >> and we worked with them over time to give them the docs they 
> >> > > > >> required.
> >> > > > >>
> >>> > > > >>>
> >>> > > > >>> I don't think this is a great idea. Mainly because they are 
> >>> > > > >>> for developers,
> >>> > > > >>> operators aren't going to be looking in there for install 
> >>> > > > >>> information. Also the
> >>> > > > >>> Developer doc page [4] even states "This page contains 
> >>> > > > >>> documentation for Python
> >>> > > > >>> developers, who work on OpenStack itself".
> >> > > > >>
> >> > > > >> I agree, but it's a great place to start. In fact, I've just 
> >> > > > >> merged a change to the Docs Contributor Guide (on the back of 
> >> > > > >> a previous mailing list conversation) that explicitly states 
> >> > > > >> this:
> >> > > > >>
> >> > > > >> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > > > > 
> > > > > > I think you're missing that most of us are disagreeing that it 
> > > > > > is
> > > > > > a good place to start. It's fine to have the docs in a 
> > > > > > repository
> > > > > > managed by the project team. It's not good at all to publish 
> > > > > > them
> > > > > > under docs.o.o/developer because they are not for developers, 
> > > > > > and
> > > > > > so it's confusing. This is why we ended up with a different 
> > > > > > place
> > > > > > for release notes to be published, instead of just adding reno 
> > > > > > to
> > > > > > the existing developer documentation build, for example.
> > > > > > 
>  > > > 
>  > > > All docs need to be drafted somewhere. I don't care where that is, 
>  > > > but make the suggestion of /developer because at least it's 
>  > > > accessible there, and also because it's managed in the project's 
>  > > > own repo. If you want to create a different place, or rename 
>  > > > /developer to be more inclusive, I think that's a great idea.
> >>> > > 
> >>> > > I think we'll want to add a new location, or publish to a similar
> >>> > > location to the existing install guide. I found, for example
> >>> > > http://docs.openstack.org/mitaka/install-guide-ubuntu/
> >>> > > 
> >>> > > If we take ironic as the example, and assume all OS-types would be
> >>> > > covered in one manual, we could make that:
> >>> > > 
> >>> > > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> >>> > > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> >>> > > (3) 

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Mike Perez]

> On Mar 25, 2016, at 06:10, Doug Hellmann  wrote:
> 
> Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
>> 
>> All docs need to be drafted somewhere. I don't care where that is, but make 
>> the suggestion of /developer because at least it's accessible there, and 
>> also because it's managed in the project's own repo. If you want to create a 
>> different place, or rename /developer to be more inclusive, I think that's a 
>> great idea.
> 
> I think we'll want to add a new location, or publish to a similar
> location to the existing install guide. I found, for example
> http://docs.openstack.org/mitaka/install-guide-ubuntu/
> 
> If we take ironic as the example, and assume all OS-types would be
> covered in one manual, we could make that:
> 
> (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> (3) http://docs.openstack.org/install-guide/ironic/
> (4) http://docs.openstack.org/ironic/install-guide/

I like option 3.

All install guides would be discoverable at /install-guides that are rendered 
docs from individual projects' repos.

Regardless of what direction people would like to go here, I will be happy to 
spearhead this from a cross-project perspective.

--
Mike Perez
__
OpenStack Development Mailing 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] Removing logs from Fuel Web UI and Nailgun

[Dmitry Pyzhov]

Anastasia,

we are going to invest one more day in investigation of high priority bug,
we cannot reproduce it at the moment. I don't think that we should fix
medium bugs in feature that soon will be deprecated.

On Fri, Mar 25, 2016 at 3:54 PM, Anastasia Urlapova 
wrote:

> Dima,
> if we want to deprecate UI logs in 10.0, it doesn't mean that we shouldn't
> fix issues in 9.0.
>
> Thank you!
>
>
> Nastya.
>
> On Fri, Mar 25, 2016 at 3:31 PM, Dmitry Pyzhov 
> wrote:
>
>> As we are going to deprecate logs on UI I'm going to mark following bugs
>> as "won't fix". Any objections?
>> High priority bug:
>> https://bugs.launchpad.net/fuel/+bug/1553170
>> Medium priority:
>> https://bugs.launchpad.net/fuel/+bug/1554546
>> https://bugs.launchpad.net/fuel/+bug/1539508
>>
>> On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko 
>> wrote:
>>
>>> Folks, I’ve registered a blueprint [1] and created an etherpad document
>>> [2] where we can co-work on the spec before posting it to a formal review.
>>> Let’s cooperate to summarize what we need to do.
>>>
>>>
>>> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun
>>> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun
>>>
>>> - romcheg
>>>
>>> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya 
>>> написав(ла):
>>> >
>>> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
>>> >> +1 to Vitaliy, it would be nice find somewhere a details for
>>> migration.
>>> >> And one more concern I should highlight - for some users logless UI
>>> may
>>> >> be challenging thing.
>>> >> The logs removing shouldn't affect the UX.
>>> >
>>> > Logs will still live at the master node's /var/log/remote
>>> >
>>> >>
>>> >>
>>> >> Nastya.
>>> >>
>>> >>
>>> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward >> >> > wrote:
>>> >>
>>> >>I think we can address it by retaining deployment logs in
>>> >>nailgun/ui, this also removes the chicken and egg problem. after
>>> LMA
>>> >>is deployed it can be allowed to re-own 'logs' button on UI once
>>> >>it's deployed, including redirecting fuel logs there.
>>> >>
>>> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
>>> >>>
>>> wrote:
>>> >>
>>> >>We can sort out details later. In a worst case, the warning
>>> will
>>> >>be there in Newton too, and feature will go away only in O*
>>> >>release. So let's proceed with the bug..
>>> >>
>>> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
>>> >>>
>>> wrote:
>>> >>
>>> >>We can add the warning, but I think before we do this we
>>> >>should have clear migration plan. According to this thread,
>>> >>some parts are still not clear.
>>> >>
>>> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
>>> >>>> >>:
>>> >>
>>> >>Deprecation warning for Fuel
>>> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.
>>> >>
>>> >>
>>> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
>>> >>> wrote:
>>> >>
>>> >>Since there are a lot of supporters for this idea,
>>> >>what do you folks think about creating a BP spec
>>> >>where we can describe what we should do in order to
>>> >>remove logs from UI and Nailgun? I also propose to
>>> >>file a bug about adding a deprecation warning to
>>> >>Mitaka release of Fuel.
>>> >>
>>> >>
>>> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
>>> >>>>> >>>> написав(ла):
>>> >>>
>>> >>>On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>>> +1 to remove logs from Fuel UI in Fuel Newton.
>>> In Fuel Mitaka we'd need to put a deprecation
>>> warning somewhere.
>>> >>>
>>> >>>I agree, there is not much sense having non
>>> >>>flexible (no content
>>> >>>filters) logs view in UI. LMA plugins shall cover
>>> >>>this area as well.
>>> >>>
>>> 
>>> 
>>> On Fri, Mar 11, 2016, 04:57 Patrick Petit
>>> >> >
>>> > wrote:
>>> 
>>> 
>>>    On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>>    (ikalnit...@mirantis.com
>>> 

Re: [openstack-dev] [nova][novaclient] host-evacuate-live command is broken in 3.3.0

[Matt Riedemann]

On 3/25/2016 11:15 AM, Sean M. Collins wrote:

Hi,

3.3.0 of python-novaclient has a serious bug, which prevents host-evacuate-live 
from working correctly.

https://github.com/openstack/python-novaclient/commit/ae598280acc46dd4ee20af78a5780a450f96b084
 appears to have changed a number of function signatures and arguments, and 
resulted in the breakage.

I have filed a bug with all the details of my findings, but I wanted to
bring it to the attention of a wider audience.

https://bugs.launchpad.net/python-novaclient/+bug/1561938

How do we proceed? Revert ae598280 ?



Fix is here:

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

You can workaround for now by passing --os-compute-api-version=2.24 in 
the command line when using that command.


Once the fix is merged I'll release 3.4.0 and backport to stable/mitaka 
for a 3.3.1 release.


Thanks for pointing this out Sean.

--

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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Jim Rollenhagen]

On Fri, Mar 25, 2016 at 11:32:58AM -0700, Mike Perez wrote:
> > On Mar 25, 2016, at 06:10, Doug Hellmann  wrote:
> > 
> > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> >> 
> >> All docs need to be drafted somewhere. I don't care where that is, but 
> >> make the suggestion of /developer because at least it's accessible there, 
> >> and also because it's managed in the project's own repo. If you want to 
> >> create a different place, or rename /developer to be more inclusive, I 
> >> think that's a great idea.
> > 
> > I think we'll want to add a new location, or publish to a similar
> > location to the existing install guide. I found, for example
> > http://docs.openstack.org/mitaka/install-guide-ubuntu/
> > 
> > If we take ironic as the example, and assume all OS-types would be
> > covered in one manual, we could make that:
> > 
> > (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> > (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> > (3) http://docs.openstack.org/install-guide/ironic/
> > (4) http://docs.openstack.org/ironic/install-guide/
> 
> I like option 3.
> 
> All install guides would be discoverable at /install-guides that are rendered 
> docs from individual projects' repos.

Yeah, that's a good point. I like it. Probably with a dropdown or
something to choose a specific version.

// jim

> 
> Regardless of what direction people would like to go here, I will be happy to 
> spearhead this from a cross-project perspective.
> 
> --
> Mike Perez
> __
> OpenStack Development Mailing 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] [FFE] Unlock Settings Tab

[Vladimir Kozhukalov]

Granted. New deadline is 21:00 UTC 03/28/2016.

Vladimir Kozhukalov

On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov 
wrote:

> Fuelers!
>
>
> We are very close to landing our feature "Unlock Settings Tab". But we
> still have a set of reviews [0] to be merged due to several reasons (incl.
> the migration to python27-db gates on OpenStack Infra). I would like to
> request extra time till Monday to land them.
>
>
> [0] - https://goo.gl/kSwej5
>
> 2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko :
>
>> Thanks for working this out! Confirming that task history remains
>> included in the scope of this FFE until the merge deadline, March 24.
>>
>> On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
>> > Hey Dmitry,
>> >
>> > I confirm that we agreed on feature design, and you can proceed with
>> > granting exception.
>> >
>> > ,- Igor
>> >
>> > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
>> >  wrote:
>> > > Hi Dmitry,
>> > >
>> > > We've reached the design consensus with Igor today. Could you please
>> remove
>> > > the conditional status of the FFE request?
>> > > As agreed: the merge deadline is March 24.
>> > >
>> > > --
>> > > WBR, Alexey Shtokolov
>> > >
>> > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko > >:
>> > >>
>> > >> Granted. Design consensus deadline for the task history part of this
>> > >> feature is extended to March 11. This does not change the merge
>> deadline
>> > >> for other parts of this feature, which is still March 24.
>> > >>
>> > >> --
>> > >> Dmitry Borodaenko
>> > >>
>> > >>
>> > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>> > >> > Dmitry,
>> > >> >
>> > >> > We are really close to have the consensus, but we need one more
>> meeting
>> > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>> > >> > decision.
>> > >> > All patches [0] are on review. The meeting is scheduled for
>> tomorrow
>> > >> > (03/11
>> > >> > 1:30pm CET).
>> > >> > Could you please grant us one more day for it?
>> > >> >
>> > >> > [0] -
>> > >> >
>> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>> > >> >
>> > >> > --
>> > >> > WBR, Alexey Shtokolov
>> > >> >
>> > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
>> dborodae...@mirantis.com>:
>> > >> >
>> > >> > > Granted, merge deadline March 24, task history part of the
>> feature is
>> > >> > > to
>> > >> > > be excluded from this exception grant unless a consensus is
>> reached by
>> > >> > > March 10.
>> > >> > >
>> > >> > > Relevant part of the meeting log starts at:
>> > >> > >
>> > >> > >
>> > >> > >
>> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>> > >> > >
>> > >> > > --
>> > >> > > Dmitry Borodaenko
>> > >> > >
>> > >> > >
>> > >> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
>> > >> > > > Oh, so there is a spec. I was worried that this patch has
>> > >> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so I
>> > >> > > > thought
>> > >> > > > there is no spec for it. So the commit message should be
>> updated to
>> > >> > > > avoid
>> > >> > > > such confusion.
>> > >> > > >
>> > >> > > > It's really good I've seen this spec. There are plans to
>> overhaul UI
>> > >> > > > data
>> > >> > > > format description which we use for cluster and node settings
>> to
>> > >> > > > solve
>> > >> > > some
>> > >> > > > issues and implement long-awaited features like nested
>> structures,
>> > >> > > > so we
>> > >> > > > might also want to deprecate our expression language and also
>> switch
>> > >> > > > to
>> > >> > > > YAQL (and thus port YAQL to JS).
>> > >> > > >
>> > >> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <
>> vkuk...@mirantis.com>:
>> > >> > > >
>> > >> > > > > Vitaly
>> > >> > > > >
>> > >> > > > > Thanks for bringing this up. Actually the spec has been on
>> review
>> > >> > > > > for
>> > >> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
>> > >> > > > > Essentially,
>> > >> > > > > this is not introducing new DSL but replacing the existing
>> one
>> > >> > > > > with
>> > >> > > more
>> > >> > > > > powerful extendable language which is being actively
>> developed
>> > >> > > > > within
>> > >> > > > > OpenStack and is already a part of other projects (Murano,
>> > >> > > > > Mistral),
>> > >> > > which
>> > >> > > > > has much more contributors, can return not only boolean but
>> any
>> > >> > > arbitrary
>> > >> > > > > collections. So it means that we want to deprecate current
>> > >> > > > > Expression
>> > >> > > > > language that you wrote and replace it with YAQL due to those
>> > >> > > > > reasons.
>> > >> > > You
>> > >> > > > > are not going to extend this Expression-based language in 3
>> weeks
>> > >> > > > > up to
>> > >> > > > > level of support of extensions, method overloading, return of
>> > >> > > > > arbitrary
>> > >> > > > > 

Re: [openstack-dev] [kite] Seeking core reviewers

[Ronald Bradford]

Thanks Doug.

I've shortened your workload a bit --
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090491.html



Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford 
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Mar 25, 2016 at 12:05 PM, Douglas Mendizábal <
douglas.mendiza...@rackspace.com> wrote:

> Thanks for the patches, Ronald.  Adam Young is right, Kite is pretty
> much dead.
>
> I'll add to my list of spring cleaning to-dos to remove Kite from
> governance and infra.
>
> Thanks,
> Douglas Mendizábal (redrobot)
>
> On 3/25/16 10:08 AM, Ronald Bradford wrote:
> > Thanks all for feedback.
> >
> > I have proposed a non maintained patch [1] based on comments here.
> > I will speak with the Barbican team.
> >
> > Ronald
> >
> > [1] https://review.openstack.org/#/c/297719/
> >
> >
> > Ronald Bradford
> >
> > Web Site: http://ronaldbradford.com 
> > LinkedIn:  http://www.linkedin.com/in/ronaldbradford
> > Twitter:@RonaldBradford 
> > Skype: RonaldBradford
> > GTalk: Ronald.Bradford
> > IRC: rbradfor
> >
> >
> > On Fri, Mar 25, 2016 at 5:02 AM, Thierry Carrez  > > wrote:
> >
> > Ian Cordasco wrote:
> >
> > I believe Kite is no longer actively developed or maintained and
> > was started by the Barbican folks. You should find them in
> > #openstack-barbican.
> >
> >
> > Yeah. It's still technically a repository under the Barbican team.
> > Someone from Barbican should propose a governance change to get rid
> > of it (or approve someone else's change getting rid of it).
> >
> > Keeping abandoned repositories in your official list does not
> > reflect well on your project team (or OpenStack in general).
> >
> > --
> > Thierry Carrez (ttx)
> >
> >
>  __
> > 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/openstack-dev

Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo branches

[Michał Jastrzębski]

+1

On 25 March 2016 at 11:36, Jeffrey Zhang  wrote:
> +1
>
> On Sat, Mar 26, 2016 at 12:07 AM, Ryan Hallisey  wrote:
>>
>> +1 for sure
>>
>> -Ryan
>>
>> - Original Message -
>> From: "Paul Bourke" 
>> To: openstack-dev@lists.openstack.org
>> Sent: Friday, March 25, 2016 11:43:06 AM
>> Subject: Re: [openstack-dev] [kolla][vote] deprecation of
>> icehosue/juno/kilo branches
>>
>> +1
>>
>> On 25/03/16 15:36, Steven Dake (stdake) wrote:
>> > Hey folks,
>> >
>> > These branches are essentially unmaintained and we have completely given
>> > up on them.  That’s ok – they were paths of our development.  I didn't
>> > really want to branch them in the first place, but the community
>> > demanded it, so I delivered that :)
>> >
>> > Now that our architecture is fairly stable in liberty and mitaka, I
>> > think it makes sense to do the following
>> > 1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol
>> > 2. Ask infrastructure to remove the branches from git
>> >
>> > This is possible; I have just verified in openstack-infra.  I'd like a
>> > vote from the core review team.  If you would like to see the kilo
>> > branch stay, please note that, and if there is a majority on
>> > icehosue/juno but not kilo I'll make the appropriate arrangements with
>> > openstack-infra.
>> >
>> > I will leave voting open for 1 week until Saturday April 2nd.  I will
>> > close voting early if there is a majority vote.
>> >
>> > Regards
>> > -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
>> >
>>
>> __
>> OpenStack Development Mailing 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
>
>
>
>
> --
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing 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] [FFE] Unlock Settings Tab

[Alexey Shtokolov]

Fuelers!


We are very close to landing our feature "Unlock Settings Tab". But we
still have a set of reviews [0] to be merged due to several reasons (incl.
the migration to python27-db gates on OpenStack Infra). I would like to
request extra time till Monday to land them.


[0] - https://goo.gl/kSwej5

2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko :

> Thanks for working this out! Confirming that task history remains
> included in the scope of this FFE until the merge deadline, March 24.
>
> On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
> > Hey Dmitry,
> >
> > I confirm that we agreed on feature design, and you can proceed with
> > granting exception.
> >
> > ,- Igor
> >
> > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
> >  wrote:
> > > Hi Dmitry,
> > >
> > > We've reached the design consensus with Igor today. Could you please
> remove
> > > the conditional status of the FFE request?
> > > As agreed: the merge deadline is March 24.
> > >
> > > --
> > > WBR, Alexey Shtokolov
> > >
> > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko  >:
> > >>
> > >> Granted. Design consensus deadline for the task history part of this
> > >> feature is extended to March 11. This does not change the merge
> deadline
> > >> for other parts of this feature, which is still March 24.
> > >>
> > >> --
> > >> Dmitry Borodaenko
> > >>
> > >>
> > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
> > >> > Dmitry,
> > >> >
> > >> > We are really close to have the consensus, but we need one more
> meeting
> > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
> > >> > decision.
> > >> > All patches [0] are on review. The meeting is scheduled for tomorrow
> > >> > (03/11
> > >> > 1:30pm CET).
> > >> > Could you please grant us one more day for it?
> > >> >
> > >> > [0] -
> > >> >
> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
> > >> >
> > >> > --
> > >> > WBR, Alexey Shtokolov
> > >> >
> > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
> dborodae...@mirantis.com>:
> > >> >
> > >> > > Granted, merge deadline March 24, task history part of the
> feature is
> > >> > > to
> > >> > > be excluded from this exception grant unless a consensus is
> reached by
> > >> > > March 10.
> > >> > >
> > >> > > Relevant part of the meeting log starts at:
> > >> > >
> > >> > >
> > >> > >
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
> > >> > >
> > >> > > --
> > >> > > Dmitry Borodaenko
> > >> > >
> > >> > >
> > >> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
> > >> > > > Oh, so there is a spec. I was worried that this patch has
> > >> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so I
> > >> > > > thought
> > >> > > > there is no spec for it. So the commit message should be
> updated to
> > >> > > > avoid
> > >> > > > such confusion.
> > >> > > >
> > >> > > > It's really good I've seen this spec. There are plans to
> overhaul UI
> > >> > > > data
> > >> > > > format description which we use for cluster and node settings to
> > >> > > > solve
> > >> > > some
> > >> > > > issues and implement long-awaited features like nested
> structures,
> > >> > > > so we
> > >> > > > might also want to deprecate our expression language and also
> switch
> > >> > > > to
> > >> > > > YAQL (and thus port YAQL to JS).
> > >> > > >
> > >> > > > 2016-03-02 17:17 GMT+07:00 Vladimir Kuklin <
> vkuk...@mirantis.com>:
> > >> > > >
> > >> > > > > Vitaly
> > >> > > > >
> > >> > > > > Thanks for bringing this up. Actually the spec has been on
> review
> > >> > > > > for
> > >> > > > > almost 2 weeks: https://review.openstack.org/#/c/282695/.
> > >> > > > > Essentially,
> > >> > > > > this is not introducing new DSL but replacing the existing one
> > >> > > > > with
> > >> > > more
> > >> > > > > powerful extendable language which is being actively developed
> > >> > > > > within
> > >> > > > > OpenStack and is already a part of other projects (Murano,
> > >> > > > > Mistral),
> > >> > > which
> > >> > > > > has much more contributors, can return not only boolean but
> any
> > >> > > arbitrary
> > >> > > > > collections. So it means that we want to deprecate current
> > >> > > > > Expression
> > >> > > > > language that you wrote and replace it with YAQL due to those
> > >> > > > > reasons.
> > >> > > You
> > >> > > > > are not going to extend this Expression-based language in 3
> weeks
> > >> > > > > up to
> > >> > > > > level of support of extensions, method overloading, return of
> > >> > > > > arbitrary
> > >> > > > > collections (e.g. we also want to calculate cross-depends and
> > >> > > > > requires
> > >> > > > > fields on the fly which require for it to return list of
> dicts)
> > >> > > > > and
> > >> > > support
> > >> > > > > of this stuff on your own, are you?
> > >> > > > >
> > >> > > > > On Wed, Mar 2, 2016 at 10:09 

Re: [openstack-dev] Which projects support wsgi / python3 in mitaka?

[Matthew Thode]

On 03/25/2016 12:27 PM, Brant Knudson wrote:
> 
> 
> On Fri, Mar 25, 2016 at 9:54 AM, Matthew Thode
> > wrote:
> 
> I'm updating the packaging for openstack in preparation for the release
> and need some info to update correctly.  I'm specifically looking at the
> following services.
> 
> I don't know if any of these services support python3 fully as a service
> (liberty was kinda wishy washy on that).  Even if it supports python3,
> which version, 3.4 or 3.4 or 3.5 (or multiple).
> 
> keystone - probably - keystone/server/wsgi.py
> 
> 
> For keystone you should use bin/keystone-wsgi-public and
> bin/keystone-wsgi-admin as the wsgi entrypoints. The gate tests use
> keystone running under mod_wsgi in apache httpd. We've also got a test
> in keystone that uses uwsgi as the container.
> 
> Keystone doesn't support python 3 in M.
> 
>  - Brant
> 
Thanks, I'll likely remove our init scripts for keystone (they started
up keystone directly using the non-wsgi method).  I'll also add a note
to either use the scripts you mentioned directly (not really good for
prod I think) and direct them to use wsgi though apache2/wsgi or uwsgi.

-- 
-- 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] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Jim Rollenhagen]

On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
> Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> > On 24/03/16 08:01, Doug Hellmann wrote:
> > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35 +1000:
> > >> Hi Mike, and sorry I missed you on IRC to discuss this there. That said, 
> > >> I think it's great that you took this to the mailing list, especially 
> > >> seeing the conversation that has ensued.
> > >>
> > >> More inline ...
> > >>
> > >> On 24/03/16 01:06, Mike Perez wrote:
> > >>> Hey all,
> > >>>
> > >>> I've been talking to a variety of projects about lack of install 
> > >>> guides. This
> > >>> came from me not having a great experience with trying out projects in 
> > >>> the big
> > >>> tent.
> > >>>
> > >>> Projects like Manila have proposed install docs [1], but they were 
> > >>> rejected
> > >>> by the install docs team because it's not in defcore. One of Manila's 
> > >>> goals of
> > >>> getting these docs accepted is to apply for the operators tag
> > >>> ops:docs:install-guide [2] so that it helps their maturity level in the 
> > >>> project
> > >>> navigator [3].
> > >>>
> > >>> Adrian Otto expressed to me having the same issue for Magnum. I think 
> > >>> it's
> > >>> funny that a project that gets keynote time at the OpenStack conference 
> > >>> can't
> > >>> be in the install docs personally.
> > >>>
> > >>> As seen from the Manila review [1], the install docs team is suggesting 
> > >>> these
> > >>> to be put in their developer guide.
> > >>
> > >> As Steve pointed out, these now have solid plans to go in. That was 
> > >> because both projects opened a conversation with us and we worked with 
> > >> them over time to give them the docs they required.
> > >>
> > >>>
> > >>> I don't think this is a great idea. Mainly because they are for 
> > >>> developers,
> > >>> operators aren't going to be looking in there for install information. 
> > >>> Also the
> > >>> Developer doc page [4] even states "This page contains documentation 
> > >>> for Python
> > >>> developers, who work on OpenStack itself".
> > >>
> > >> I agree, but it's a great place to start. In fact, I've just merged a 
> > >> change to the Docs Contributor Guide (on the back of a previous mailing 
> > >> list conversation) that explicitly states this:
> > >>
> > >> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > 
> > > I think you're missing that most of us are disagreeing that it is
> > > a good place to start. It's fine to have the docs in a repository
> > > managed by the project team. It's not good at all to publish them
> > > under docs.o.o/developer because they are not for developers, and
> > > so it's confusing. This is why we ended up with a different place
> > > for release notes to be published, instead of just adding reno to
> > > the existing developer documentation build, for example.
> > > 
> > 
> > All docs need to be drafted somewhere. I don't care where that is, but make 
> > the suggestion of /developer because at least it's accessible there, and 
> > also because it's managed in the project's own repo. If you want to create 
> > a different place, or rename /developer to be more inclusive, I think 
> > that's a great idea.
> 
> I think we'll want to add a new location, or publish to a similar
> location to the existing install guide. I found, for example
> http://docs.openstack.org/mitaka/install-guide-ubuntu/
> 
> If we take ironic as the example, and assume all OS-types would be
> covered in one manual, we could make that:
> 
> (1) http://docs.openstack.org/mitaka/ironic/install-guide/
> (2) http://docs.openstack.org/ironic/mitaka/install-guide/
> (3) http://docs.openstack.org/install-guide/ironic/
> (4) http://docs.openstack.org/ironic/install-guide/
> 
> I like options 3 and 4. To keep things simple for the project teams,
> I think we want to skip including the release series in the base
> URL.  As the instructions change, projects may need to create
> separate sub-sections of their guide for each series, but they
> should be able to do that without having to set up separate publishing
> locations and jobs.
> 
> Another benefit of options 3 and 4 is that as the ironic team
> produces other guides, those can go under a consistent URL that
> makes it relatively simple to set up a generic publishing job for
> all projects. Option 4 does have the benefit of making it easy to
> have a page at http://docs.openstack.org/ironic/ linking to all of
> the guides the ironic team has published.
> 
> Thoughts?

I also like 3 and 4. I like 3 because it's a similar structure to the
developer docs, however I do like 4 giving us the option to publish
other guides (and perhaps we could move the developer docs to
/ironic/developer).

I do think we should be able to publish per-release versions of the
install guide (or any other guides) similar to how we publish developer
docs per-release today. For example:

Re: [openstack-dev] [oslo][messaging][zmq][performance]

[Joshua Harlow]

Out of curiosity for this, is it a generally applicable solution that 
could also be used for the other in(secure) messaging issues that have 
been talked about in:


http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90082

On 03/25/2016 05:28 AM, Oleksii Zamiatin wrote:

6. Support encryption for messages (libsodium etc.)


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