Re: [openstack-dev] [puppet] Ubuntu problems + Help needed

2017-12-20 Thread Andrew Woodward
Some pointers for perusal as to the observed problems would be helpful,
Thanks!

On Wed, Dec 20, 2017 at 11:09 AM Chuck Short <zul...@gmail.com> wrote:

> Hi Mohammed,
>
> I might be able to help where can I find this info?
>
> Thanks
> chuck
>
> On Wed, Dec 20, 2017 at 12:03 PM, Mohammed Naser <mna...@vexxhost.com>
> wrote:
>
>> Hi everyone,
>>
>> I'll get right into the point.
>>
>> At the moment, the Puppet OpenStack modules don't have much
>> contributors which can help maintain the Ubuntu support.  We deploy on
>> CentOS (so we try to get all the fixes in that we can) and there is a
>> lot of activity from the TripleO team as well which does their
>> deployments on CentOS which means that the CentOS support is very
>> reliable and CI is always sought after.
>>
>> However, starting a while back, we started seeing occasional failures
>> with Ubuntu deploys which lead us set the job to non-voting.  At the
>> moment, the Puppet integration jobs for Ubuntu are always failing
>> because of some Tempest issue.  This means that with every Puppet
>> change, we're wasting ~80 minutes of CI run time for a job that will
>> always fail.
>>
>> We've had a lot of support from the packaging team at RDO (which are
>> used in Puppet deployments) and they run our integration before
>> promoting packages which makes it helpful in finding issues together.
>> However, we do not have that with Ubuntu neither has there been anyone
>> who is taking initiative to look and investigate those issues.
>>
>> I understand that there are users out there who use Ubuntu with Puppet
>> OpenStack modules.  We need your help to come and try and clear those
>> issues out. We'd be more than happy to give assistance to lead you in
>> the right way to help fix those issues.
>>
>> Unfortunately, if we don't have any folks stepping up to resolving
>> this, we'll be forced to drop all CI for Ubuntu and make a note to
>> users that Ubuntu is not fully tested and hope that as users run into
>> issues, they can contribute fixes back (or that someone can work on
>> getting Ubuntu gating working again).
>>
>> Thanks for reading through this, I am quite sad that we'd have to drop
>> support for such a major operating system, but there's only so much we
>> can do with a much smaller team.
>>
>> Thank you,
>> Mohammed
>>
>> __
>> OpenStack Development Mailing 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
>
-- 
Andrew Woodward
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [puppet][puppet-ceph]

2017-09-05 Thread Andrew Woodward
On Tue, Sep 5, 2017 at 6:47 AM Mohammed Naser <mna...@vexxhost.com> wrote:

> On Tue, Sep 5, 2017 at 4:15 AM, Emil Enemærke <enema...@gmail.com> wrote:
> > Hi,
> >
> > I have stated using the puppet-ceph module for deploying ceph, and have
> > noticed a heavy use of exec in fx define 'ceph::osd'
> > (https://github.com/openstack/puppet-ceph/blob/master/manifests/osd.pp).
> Is
> > there a reason for not writing this define as an ensurable type/provider?
> > Otherwise I will fork the module an start on rewriting it for a
> > type/provider.
> >
>
> Thanks for helping out.  I'm happy to see folks using the puppet-ceph
> modules!  I think the reason why we've relied of the Exec's is purely
> historic.  If you have a patch that would convert it to an ensurable
> type and provider, we'd be more than happy to merge it!
>

As manser pointed out, the reason for the exec's is purely historic, in
that the initial implementation team  wasn't comfortable with developing
ruby providers given our familiarity at the time. It was easier for us to
develop and troubleshoot the execs directly.

We'd be more than happy to have reviews to migrate to a ruby implementation

If you have any questions, feel free to pop by on #puppet-openstack on
freenode


> >
> > Cheers
> > Emil
> >
> >
> __
> > OpenStack Development Mailing 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
>
-- 
Andrew Woodward
__
OpenStack Development Mailing 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] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

2016-10-11 Thread Andrew Woodward
removing the directory include, proposed
structure, service config files could simply be /etc/nova/$service.conf

We should make per-service config files standard in the upstream
themselves, and this is an area where we need to collaborate with Debian as
well. At the same time, we should also be thinking about multiple instances
support for services (a.k.a cinder-volume) that may run multiple instances
but with different config files. Ceph does this quite well with the radosgw
service.


> > > - /usr/share/doc/packages/openstack-nova/nova.conf.sample
>
> > > The unmodified sample config from upstream
>
> > >
>
> > > - /etc/nova/README
>
> > > Explaining the configuration structure and where to find the whole
>
> > > sample config.
>
> > >
>
> >
>
> > From a packaging standpoint it's probably better to provide less and
>
> > not more default configuration files as the tooling usually has to go
>
> > an clean this stuff up as they have their own ways of configuring the
>
> > services.  Currently they may align with the existing packaging files
>
> > or they may completely remove what's provided via packaging and setup
>
> > their own structure.  Speaking from experience, having to cleanup
>
> > package provided configuration files is a pain[0][1].
>
>
>
> There are not more config files with this proposal. It's the same
>
> amount, just more possibilities. the nova-dist.conf is already in use
>
> for RDO and neutron [2]. This would be just used for all services.
>
> /etc/$service/$service.conf is the usual thing and also read by default
>
> by oslo.config . The conf.d directory delivered by a package would be
>
> completly empty. So nothing to cleanup there.
>
>
>
> [2]
>
>
> https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-server.service
>
>
>
> >
>
> > [0]
> https://github.com/openstack/puppet-horizon/blob/master/manifests/wsgi/apache.pp#L115-L128
>
> > [1]
> https://github.com/openstack/puppet-tripleo/blob/master/manifests/ui.pp#L94-L107
>
> >
>
> > >
>
> > > So starting nova-api would be:
>
> > > nova-api --config-file /usr/share/nova/nova-dist.conf
>
> > >  --config-file /etc/nova/nova.conf
>
> > >  --config-dir /etc/nova/conf.d/common/
>
> > >  --config-dir /etc/nova/conf.d/nova-api/
>
> > >
>
> >
>
> > So from a puppet standpoint we actually go out of our way to default
>
> > to the python defaults and we may purge all values not explicitly set
>
> > via puppet. This would break our assumptions around this.  I
>
> > personally do not agree with forcing the *-dist.conf into the loading
>
> > path as this may also cause issues with unwanted values being injected
>
> > by packagers.
>
>
>
> This is already happening in RDO+neutron. See [2]. So nothing new here.
>
>
>
> > The danger for people who use puppet is that we
>
> > currently expected some values to not be defined in the configuration
>
> > files thus falling back to the python defaults. If they now get
>
> > defined in service-dist.conf and we undefine it in service.conf
>
> > (because that's what we currently configure),  the end user is now
>
> > going to get a value they did not expect or want.
>
>
>
> It's not about providing a complete config (which wouldn't work anyway)
>
> but setting for some values sane defaults. See [3].
>
>
>
> [3]
>
>
> https://github.com/rdo-packages/neutron-distgit/blob/rpm-master/neutron-dist.conf
>
>
>
> > >
>
> > > The order of command line switches (--config-file/--config-dir) is
>
> > > important here. Also --config-dir is ordering the files. So adding a
>
> > > config snippet to /etc/nova/conf.d/nova-api/ with
>
> > > e.g. [DEFAULT]bind_port would override the option from the previous
>
> > > configs (last found option wins).
>
> > >
>
> >
>
> > This gets complicated to follow and may lead to issues on the user
>
> > side when ordering is a problem or attempting to debug issues. I think
>
> > this can lead to more issues than it's solving.
>
>
>
> Most services print the complete config when running in debug mode. So
>
> getting th used config is not complicated. Also adding theses switches
>
> makes it more explicit when doing e.g. "ps awxu|grep nova-api" because
>
> you see then what Also knowing which files/dirs are used is just "ps
>
> awxu|grep $service".
>
> And afaik oslo.config already loads implicit config files if they are
>
> present.
>
>
>
> > Personally unless this structure is also followed by the deb
>
> > packaging, I'd prefer not to switch to this as it may lead to even
>
> > more fragmentation when it comes to trying to configure OpenStack
>
> > deployed via packages.  Has this been requested by an end user to
>
> > solve a specific problem?  What exactly is the problem that's trying
>
> > to be solved other than trying to allow for two of the same project's
>
> > services being configured in (currently) conflicting fashions?
>
>
>
> See my anwers above. It's not only about different configs for different
>
> service.
>
>
>
> Thanks for the feedback!
>
>
>
> Cheers,
>
>
>
> Tom
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
Andrew Woodward
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Fuel] Weekly meeting for 9/29 is canceled

2016-09-29 Thread Andrew Woodward
The agenda [0] is empty again this week so the meeting is closed, see you
again next week

[0] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 
Andrew Woodward
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [fuel] Meeting for today is canceled

2016-09-15 Thread Andrew Woodward
We have nothing slated on the agenda [1] for today, so I'm calling it for
the meeting.

As usual, if you have anything to discuss, please raise it on the ML or in
#fuel.

[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 
Andrew Woodward
Mirantis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] FFE request for Ceph RGW integration

2016-09-14 Thread Andrew Woodward
Great to hear, nice work all.

On Wed, Sep 14, 2016 at 7:56 AM Giulio Fidente <gfide...@redhat.com> wrote:

> On 08/30/2016 06:40 PM, Giulio Fidente wrote:
> > Together with Keith we're working on some patches to integrate (via
> > puppet-ceph) the deployment of Ceph RGW in TripleO as a composable
> > service which can optionally replace SwiftProxy
> >
> >
> > Changes are tracked via blueprint at:
> >
> > https://blueprints.launchpad.net/tripleo/+spec/ceph-rgw-integration
> >
> > They should be tagged with the appropriate topic branch, so can be found
> > with:
> >
> > https://review.openstack.org/#/q/topic:bp/ceph-rgw-integration,n,z
> >
> >
> > There is also a [NO MERGE] change which we use to test the above in
> > upstream CI:
> >
> > https://review.openstack.org/#/c/357182/
> >
> >
> > We'd like to formally request an FFE for this feature.
> >
> > Thanks for consideration, feedback, help and reviews :)
>
> a quick update,
>
> the last submission needed for this feature has been merged today,
> thanks to all who helped
>
> from the RC release it will be possible to use ceph/rgw as a swift
> drop-in replacement for those deploying ceph
> --
> Giulio Fidente
> GPG KEY: 08D733BA | IRC: gfidente
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
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


Re: [openstack-dev] [puppet] Creating a Cloudkitty Puppet module

2016-09-01 Thread Andrew Woodward
Jinx!

On Thu, Sep 1, 2016 at 12:09 PM Alex Schultz <aschu...@redhat.com> wrote:

> On Thu, Sep 1, 2016 at 12:51 PM, Guillaume Espanel
> <guillaume.espa...@objectif-libre.com> wrote:
> > Hi!
> >
> > At the moment, I don't think theres a Puppet module for
> > the Cloudkitty rating service. I'd like to start the development
> > of this project.
> >
> > What are you thoughts on the matter?
> >
>
> Sounds good. We've put together some documentation on where to start.
>
> http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html
>
> If you have any questions or need help, feel free to visit
> #puppet-openstack on freenode.
>
> Thanks,
> -Alex
>
> > --
> > Guillaume Espanel
> > Objectif Libre www.objectif-libre.com
> > Infrastructure et Formations Linux
> >
> >
> __
> > OpenStack Development Mailing 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
>
-- 

--

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


[openstack-dev] [fuel] Meeting for Aug - 18 is canceled

2016-08-18 Thread Andrew Woodward
The agenda [1] for today's meeting has no items, so I'm calling it for the
meeting this week.

Please review your action items from last meeting and update the ML if you
haven't done so already

romcheg to annouunce fuel2 promotion and old fuel CLI removal on ML
akscram to send ML about moving cluster_upgrade extension
gkibardin to follow up on ML about mcollective config issues
xarses will update spec regarding release naming and summarize on ML

[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


[openstack-dev] [Puppet] Puppet OpenStack Application Module

2016-08-15 Thread Andrew Woodward
I'd like to propose the creation of a puppet module to make use of Puppet
Application orchestrator. This would consist of a Puppet-4 compatible
module that would define applications that would wrap the existing modules.

This will allow for the establishment of a shared module that is capable of
expressing OpenStack applications using the new language schematics in
Puppet 4 [1] for multi-node application orchestration.

I'd expect that initial testing env would consist of deploying a PE stack,
and using docker containers as node primitives. This is necessary until a
FOSS deployer component like [2] becomes stable, at which point we can
switch to it and use the FOSS PM as well. Once the env is up, I plan to
wrap p-o-i profiles to deploy the cloud and launch tempest for functional
testing.

[1] https://docs.puppet.com/pe/latest/app_orchestration_workflow.html

[2] https://github.com/ripienaar/mcollective-choria

-- 

--

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


[openstack-dev] [fuel] Meeting for today 7/28 is caneled

2016-07-28 Thread Andrew Woodward
The meeting agenda is empty for this week's meeting is empty so I'm calling
it on the meeting.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


[openstack-dev] [fuel] Fuel meeting Canceled

2016-07-21 Thread Andrew Woodward
Again the agenda [1] is empty again so I'm calling it on the meeting this
week.

[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


[openstack-dev] [fuel] IRC meeting for Jul - 14

2016-07-14 Thread Andrew Woodward
The meeting agenda is again empty, so I'm calling the meeting canceled.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

-- 

--

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


[openstack-dev] [fuel] Weekly meeting for July 7

2016-07-07 Thread Andrew Woodward
There is no agenda on the meeting again this week so I am calling it
canceled.

Thanks
-- 

--

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


[openstack-dev] [fuel] Weekly meeting 6/30 Cancled

2016-06-30 Thread Andrew Woodward
Nothing is on the agenda this week, so I'm calling to cancel the meeting.
If you have anything to discuss. Please come chat in #fuel or add it to the
agenda to discuss next week.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


Re: [openstack-dev] [fuel][plugins][ovs]

2016-06-24 Thread Andrew Woodward
You can track the fuel version supported by examining the metadata.yaml in
the root of the plugin repo. Since there is no stable/7.0 tag the last
point before metadata.yaml was changed to 8.0 is
https://github.com/openstack/fuel-plugin-ovs/tree/3776734a7b93ac440aa7b2e730d743b8510aac25
You
can try building from there but your on your own to get it to work.


On Fri, Jun 24, 2016 at 10:33 AM Ankit Chilakapaty -X (achilaka - SRS
CONSULTING INC at Cisco) <achil...@cisco.com> wrote:

> Hello,
>
>
>
> I’m trying to install ovs with dpdk 2.4/2.2 plugin for openstack kilo
> mirantis 7.0. I’m not sure if there is a compatible version for that on the
> github openstack/fuel-plugin-ovs . If there is one, could you upload the
> plugin.
>
>
>
> Thanks
>
>
>
>
>
> [image: banner11]
>
>
>
> *Ankit Chilakapaty*
>
> Engineer - IT
>
> achil...@cisco.com
>
> Tel:
>
> *Cisco Systems, Inc.*
>
>
>
>
> United States
> cisco.com
>
>
>
> [image: http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think
> before you print.
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> Please click here
> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
> Company Registration Information.
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [Fuel] Merge IRC channels

2016-06-24 Thread Andrew Woodward
There is also #fuel-devops

I never liked having all the channels, so +1

On Fri, Jun 24, 2016 at 4:25 AM Anastasia Urlapova <aurlap...@mirantis.com>
wrote:

> Vova,
> please don't forget merge #fuel-qa into a #fuel
>
> On Fri, Jun 24, 2016 at 1:55 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Nice. #fuel-infra is to merged as well.
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova <
>> afedor...@mirantis.com> wrote:
>>
>>> And +1 for #fuel-infra
>>>
>>> As of now it will be more useful if infra issues related to project will
>>> be visible for project developers. We don't have much infra-related traffic
>>> on IRC for now, and we will be able to split again if we got it.
>>>
>>> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
>>>> Dear colleagues,
>>>>
>>>> We have a few IRC channels but the level of activity there is quite low.
>>>>
>>>> #fuel
>>>> #fuel-dev
>>>> #fuel-python
>>>> #fuel-infra
>>>>
>>>> My suggestion is to merge all these channels into a single IRC channel
>>>> #fuel.
>>>> Other #fuel-* channels are to be deprecated.
>>>>
>>>> What do you think of this?
>>>>
>>>>
>>>> Vladimir Kozhukalov
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Aleksandra Fedorova
>>> Fuel CI Engineer
>>> bookwar
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
-- 

--

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


[openstack-dev] [fuel] Weekly meeting for today canceled.

2016-06-23 Thread Andrew Woodward
There is nothing in the agenda for the meeting today, so the meeting is
canceled

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
.
-- 

--

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


[openstack-dev] [Fuel] Meeting for May 5 Cancled

2016-05-05 Thread Andrew Woodward
Due to the empty agenda, and many people on holiday this week, We will
cancel today's meeting.

Meetings will resume on May 12 with their regularly scheduled programming
-- 

--

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


[openstack-dev] [fuel] Release notes with reno

2016-05-03 Thread Andrew Woodward
To follow up one of the points brought up in the fuel-plugins [1] session.
We briefly discussed using reno [2]. The system appears to be quite clean
and concise and will work for this need, and should work for general
release notes.

I'd propose that we start using reno to catalog changes to the plug-in
interfaces and encourage usage elsewhere.

I'd like to start a discussion about this further.

[1] https://etherpad.openstack.org/p/austin-summit-fuel-plugins
[2] http://docs.openstack.org/developer/reno/

-- 

--

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


Re: [openstack-dev] [puppet] Austin summit sessions recap

2016-05-03 Thread Andrew Woodward
On Tue, May 3, 2016 at 6:38 AM Emilien Macchi <emil...@redhat.com> wrote:

> Here's a summary of Puppet OpenStack sessions [1] during Austin summit.
>
> * General feedback is excellent, things are stable, no major changes
> are coming during the next cycle.
> * We discussed about the work we want to do during Newton cycle [2]:
>
> Ubuntu 16.04 LTS
> Make Puppet OpenStack modules working and gated on Ubuntu 16.04,
> starting from Newton.
> Keep stable/mitaka and before gated on Ubuntu 14.04 LTS.
>
> Release management with trailing cycle
> The release model changed to:
> http://governance.openstack.org/reference/tags/release_cycle-trailing.html
> We'll start producing milestones within a cycle, continue efforts on
> tarballs and investigate package builds (rpm, etc).
>

We spoke some about marking point releases more often. On stable it sounded
like everyone was in favor for this to be automated. I didn't catch how we
wanted to handle dev milestones


>
> Move documentation out from Wiki
> See [3].
>
> puppet-pacemaker unification
> Mirantis & Red Hat to continue collaboration on merging efforts on
> puppet-pacemaker module: https://review.openstack.org/#/c/296440/)
> So both Fuel & TripleO will use the same Puppet module to deploy Pacemaker.
>
> CI stabilization
> We're supporting 18 months old releases, so we will continue all
> efforts to stabilize our CI and make it robust so it does not break
> every morning.


Does this make it the last 3 releases + dev = 4 or the last 2 + dev? Since
-3 technically falls off when the next dev cycle starts

>
>
Containers
> Most of containers deployments have common bits (user/group
> management, config files management, etc).
> We decided that we would add the common bits in our modules, so they
> can be used by people deploying OpenStack in containers. See [4].
>
> [1] https://etherpad.openstack.org/p/newton-design-puppet
> [2] https://etherpad.openstack.org/p/newton-puppet-project-status
> [3] https://etherpad.openstack.org/p/newton-puppet-docs
> [4] https://etherpad.openstack.org/p/newton-puppet-multinode-containers
>
>
> As a retrospective, we've noticed that we had a quiet agenda &
> sessions this time, without critical things. It is a sign for our
> group things are now very stable and we did an excellent job to be at
> this point.
> Thanks for everyone who attended our sessions, feel free to add more
> things that I might have missed, or any questions.
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
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


Re: [openstack-dev] [all] cross-project deployment tool meeting

2016-04-26 Thread Andrew Woodward
Please include me, I'm in GMT-7, so UTC 1600 is the earliest I can
participate.

On Tue, Apr 26, 2016 at 11:55 AM Jan Klare <j.kl...@cloudbau.de> wrote:

> Hi,
>
>  i just wanted to follow up on this session (
> https://etherpad.openstack.org/p/newton-deployment-tools-discussion) were
> we talked about a cross-project meeting for deployment tools. I would love
> to see something like that happen and it would be great if we can find a
> specific date (maybe monthly) to do something like that. If you are
> interested in going to such a meeting, please reply to this mail with a
> suggestion when you could join such a meeting.
>
> Cheers,
> Jan (OpenStack Chef)
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


[openstack-dev] [fuel] Weekly meeting canceled for 4/28

2016-04-22 Thread Andrew Woodward
We discussed in the meeting next week that, we will cancel the next week's
IRC meeting due to summit activities.

The meeting will resume its regular schedule on May-5
-- 

--

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


[openstack-dev] [puppet][ceph] Puppet-ceph is now a formal member of puppet-openstack

2016-04-11 Thread Andrew Woodward
It's been a while since we started the puppet-ceph module on stackforge as
a friend of OpenStack. Since then Ceph's usage in OpenStack has increased
greatly and we have both the puppet-openstack deployment scenarios as well
as check-trippleo running against the module.

We've been receiving leadership from the puppet-openstack team for a while
now and our small core team has struggled to keep up. As such we have added
the puppet-openstack cores to the review ACL's in gerrit and have been
formally added to the puppet-openstack project in governance. [1]

I thank the puppet-openstack team for their support and, I am glad to see
the module move under their leadership.

[1] https://review.openstack.org/300191
-- 

--

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


Re: [openstack-dev] [all] Newton Summit: cross-project session for deployment tools projects

2016-04-01 Thread Andrew Woodward
An obvious +1 from me as well

On Fri, Apr 1, 2016 at 10:25 AM Paul Belanger <pabelan...@redhat.com> wrote:

> On Thu, Mar 31, 2016 at 05:40:53PM -0400, Emilien Macchi wrote:
> > Hi,
> >
> > OpenStack big tent has different projects for deployments: Puppet,
> > Chef, Ansible, Kolla, TripleO, (...) but we still have some topics  in
> > common.
> > I propose we use the Cross-project day to meet and talk about our
> > common topics: CI, doc, release, backward compatibility management,
> > etc.
> >
> > Feel free to look at the proposed session and comment:
> > https://etherpad.openstack.org/p/newton-cross-project-sessions
> >
> > Thanks,
> > --
> > Emilien Macchi
> I'm intereted in this too!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


[openstack-dev] [fuel][ConfigDB] Separating node and cluster serialized data

2016-03-31 Thread Andrew Woodward
One of the problems we've faced with trying to plug-in ConfigDB is trying
to separate the cluster attributes from the node attributes in the
serialized output (ie astute.yaml)

I started talking with Alex S about how we could separate them after
astute.yaml is prepared trying to ensure which was which we came back
uncertain that the results would be accurate.

So I figured I'd go back to the source and see if there was a way to know
which keys belonged where. It turns out that we could solve the problem in
a simpler and more precise way than cutting them back apart later.

Looking over the deployment_serializers.py [1] the serialized data follows
a simple work flow

iterate over every node in cluster
  if node is customized:
serialized_data = node.replaced_deployment_data
  else:
serialized_data = dict_merge(
  serialize_node(node),
  get_common_attrs(cluster))

Taking this into mind, we can simply construct an extension to expose these
as an APIs so that we can consume them as a task in the deployment graph.

Cluster:
We can simply expose
DeploymentMultinodeSerializer().get_common_attrs(cluster)

This would then be plumbed to the cluster level in ConfigDB

Node:
if a Node has customized data, then we can return that at the node level,
this continues to work at the same as native since it most likely has
Cluster merged into it.

otherwise we can return the serialized node with whichever of the first
'role' the node has

We would expose DeploymentMultinodeSerializer().serialize_node(node,
objects.Node.all_roles(node)[0])

for our usage, we don't need to worry about the normal node role
combination as the data only influences 'role' and 'fail_if_error'
attributes, both are not consumed in the library.

https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L93-L121
-- 

--

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


Re: [openstack-dev] [release][puppet] Puppet OpenStack 8.0.0 release (mitaka)

2016-03-29 Thread Andrew Woodward
Absolutely fantastic. Great job Emilien and the Puppet-Openstack team.
We've made great progress cycle over cycle, and now have closed our release
before most of the projects we support.

On Mon, Mar 28, 2016 at 3:55 PM Emilien Macchi <emil...@redhat.com> wrote:

> Puppet OpenStack team has the immense pleasure to announce the release
> of 24 Puppet modules.
>
> Some highlights and major features:
>
> Keystone:
> * Federation with Mellon support
> * Support for multiple LDAP backends
> * Usage of keystone-manage bootstrap
>
> Neutron:
> * Support of LBaaSv2
> * More SDN integrations: OpenDayLight, PlugGrid, Midonet
> * Use modern parameters for Nova notifications
>
> Nova:
> * Manage Nova API database
> * Nova cells support with host aggregates
> * Remove EC2 support
> * Provider to manage security groups and rules
>
> Glance:
> * Multi-backend support
> * Glare API support
>
> Cinder:
> * Block Device backend support
> * Allow to deploy Cinder API v3
>
> General features:
> * IPv6 deployment support
> * CI continues to have more use-cases coverage
>
> New stable modules:
> * puppet-mistral
> * puppet-zaqar
>
>
> Detailed Release notes:
>
> http://docs.openstack.org/releasenotes/puppet-aodh
> http://docs.openstack.org/releasenotes/puppet-ceilometer
> http://docs.openstack.org/releasenotes/puppet-cinder
> http://docs.openstack.org/releasenotes/puppet-designate
> http://docs.openstack.org/releasenotes/puppet-glance
> http://docs.openstack.org/releasenotes/puppet-gnocchi
> http://docs.openstack.org/releasenotes/puppet-heat
> http://docs.openstack.org/releasenotes/puppet-horizon
> http://docs.openstack.org/releasenotes/puppet-ironic
> http://docs.openstack.org/releasenotes/puppet-keystone
> http://docs.openstack.org/releasenotes/puppet-manila
> http://docs.openstack.org/releasenotes/puppet-mistral
> http://docs.openstack.org/releasenotes/puppet-murano
> http://docs.openstack.org/releasenotes/puppet-neutron
> http://docs.openstack.org/releasenotes/puppet-nova
> http://docs.openstack.org/releasenotes/puppet-openstack_extras
> http://docs.openstack.org/releasenotes/puppet-openstacklib
> http://docs.openstack.org/releasenotes/puppet-openstack_spec_helper
> http://docs.openstack.org/releasenotes/puppet-sahara
> http://docs.openstack.org/releasenotes/puppet-swift
> http://docs.openstack.org/releasenotes/puppet-tempest
> http://docs.openstack.org/releasenotes/puppet-trove
> http://docs.openstack.org/releasenotes/puppet-vswitch
> http://docs.openstack.org/releasenotes/puppet-zaqar
>
>
> Big kudos to the team and also our friends from OpenStack Infra, RDO,
> UCA, and Tempest!
> --
> Emilien Macchi on behalf of Puppet OpenStack team
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


[openstack-dev] [Fuel] Where the FU(EL) did my puppet files go?

2016-03-24 Thread Andrew Woodward
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
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


Re: [openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

2016-03-21 Thread Andrew Woodward
I've mocked up the change to implementation using the already landed
changes to ceph as an example

https://review.openstack.org/295571

On Mon, Mar 21, 2016 at 3:44 PM Andrew Woodward <xar...@gmail.com> wrote:

> We had originally planned for the FFEs for both fuel-openstack-tasks[1]
> and fuel-remove-conflict-openstack to [2] to close on 3/20, This would have
> placed them before changes that conflict with
> fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3].
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089028.html
>
> However we found this morning that the changes from [2], and more of issue
> [1] will result in further issues such as [4], where as the task files
> move, any task that explicitly relied on it, now no longer is in the same
> path.
>
> [4] https://review.openstack.org/#/c/295170/
>
> Due to this newly identified issue with backwards comparability. It
> appears that [4] shows that we have plugins using interfaces that we don't
> have formal coverage for so If we introduce this set of changes, we will
> cause breakage for plugins that use fuel's current tasks.
>
> From a deprecation standpoint we don't have a way to deal with this,
> unless  fuel-openstack-tasks [1] lands after
> fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. In this
> case we can take advantage of the class include stubs, leaving a copy in
> the old location (osnailyfacter/modular/roles/compute.pp) pointing to the
> new include location (include openstack_tasks::roles::compute) and adding a
> warning for deprecation. The tasks includes in the new location
> openstack_tasks/examples/roles/compute.pp would simply include the updated
> class location w/o the warning.
>
> This would take care of [1] and it's review [5]
>
> [5] https://review.openstack.org/283332
>
> This still leaves [2] un-addressed, we still have 3 open CR for it:
>
> [6] Compute https://review.openstack.org/285567
> [7] Cinder https://review.openstack.org/294736
> [8] Swift https://review.openstack.org/294979
>
> Compute [6] is in good shape, while Cinder [7] and Swift [8] are not. For
> these do we want to continue to land them, if so what do we want to do
> about the now deprecated openstack:: tasks? We could leave them in place
> with a warning since we would not be using them
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
-- 

--

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


[openstack-dev] [fuel] FFE for fuel-openstack-tasks and fuel-remove-conflict-openstack

2016-03-21 Thread Andrew Woodward
We had originally planned for the FFEs for both fuel-openstack-tasks[1] and
fuel-remove-conflict-openstack to [2] to close on 3/20, This would have
placed them before changes that conflict with
fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3].

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088297.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/088298.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089028.html

However we found this morning that the changes from [2], and more of issue
[1] will result in further issues such as [4], where as the task files
move, any task that explicitly relied on it, now no longer is in the same
path.

[4] https://review.openstack.org/#/c/295170/

Due to this newly identified issue with backwards comparability. It appears
that [4] shows that we have plugins using interfaces that we don't have
formal coverage for so If we introduce this set of changes, we will cause
breakage for plugins that use fuel's current tasks.

>From a deprecation standpoint we don't have a way to deal with this, unless
 fuel-openstack-tasks [1] lands after
fuel-refactor-osnailyfacter-for-puppet-master-compatibility [3]. In this
case we can take advantage of the class include stubs, leaving a copy in
the old location (osnailyfacter/modular/roles/compute.pp) pointing to the
new include location (include openstack_tasks::roles::compute) and adding a
warning for deprecation. The tasks includes in the new location
openstack_tasks/examples/roles/compute.pp would simply include the updated
class location w/o the warning.

This would take care of [1] and it's review [5]

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

This still leaves [2] un-addressed, we still have 3 open CR for it:

[6] Compute https://review.openstack.org/285567
[7] Cinder https://review.openstack.org/294736
[8] Swift https://review.openstack.org/294979

Compute [6] is in good shape, while Cinder [7] and Swift [8] are not. For
these do we want to continue to land them, if so what do we want to do
about the now deprecated openstack:: tasks? We could leave them in place
with a warning since we would not be using them

-- 

--

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


Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

2016-03-19 Thread Andrew Woodward
 gate.
> >> > > > >
> >> > > > > I propose to move the module to OpenStack so we'll use
> >> > > > OpenStack Infra
> >> > > > > benefits (Gerrit, Releases, Gating, etc). Another idea would
> >> > > > be to
> >> > > > gate
> >> > > > > the module with TripleO HA jobs.
> >> > > > >
> >> > > > > The question is, under which umbrella put the module?
> Puppet ?
> >> > > > TripleO ?
> >> > > > >
> >> > > > > Or no umbrella, like puppet-ceph. <-- I like this idea
> >> > > >
> >> > > >
> >> > > > I think the module not being under an umbrella makes sense.
> >> > > >
> >> > > >
> >> > > > >
> >> > > > > Any feedback is welcome,
> >> > > > >
> >> > > > > [1] https://github.com/redhat-openstack/puppet-pacemaker
> >> > > >
> >> > > > Seems like a module that would be useful outside of TripleO,
> so
> >> > > > it
> >> > > > doesn't seem like it should live under that.  Other than that
> I
> >> > > > don't
> >> > > > have enough knowledge of the organization of the puppet
> modules
> >> > > > to
> >> > > > comment.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> __
> >> > > > 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
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Juan Antonio Osorio R.
> >> > > > e-mail: jaosor...@gmail.com <mailto:jaosor...@gmail.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
> >> > > >
> >> > >
> >> > > --
> >> > > Emilien Macchi
> >> > >
> >> > >
> >> > >
> __
> >> > > OpenStack Development Mailing List (not for usage questions)
> >> > > Unsubscribe:
> >> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > Email had 1 attachment:
> >> > > + signature.asc
> >> > >   1k (application/pgp-signature)
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [Fuel] Getting rid of cluster status

2016-03-15 Thread Andrew Woodward
On Tue, Mar 15, 2016 at 4:04 AM Roman Prykhodchenko <m...@romcheg.me> wrote:

> Fuelers,
>
> I would like to continue the series of "Getting rid of …" emails. This
> time I’d like to talk about statuses of clusters.
>
> The issues with that attribute is that it is not actually related to real
> world very much and represents nothing. A few month ago I proposed to make
> it more real-world-like [1] by replacing a simple string by an aggregated
> value. However, after task based deployment was introduced even that
> approach lost its connection to the real world.
>
> My idea is to get rid of that attribute from a cluster and start working
> with status of every single node in it. Nevertheless, we only have tasks
> that are executed on nodes now, so we cannot apply the "status" term to
> them. What if we replace that with a sort of boolean value called
> maintenance_mode (or similar) that we will use to tell if the node is
> operational or not. After that we will be able to use an aggregated
> property for cluster and check, if there are any nodes that are under a
> progress of performing some tasks on them.
>

Yes, we still need an operations attribute, I'm not sure a bool is enough,
but you are quite correct, setting the status of the cluster after
operational == True based on the result of a specific node failing, is in
practice invalid.

At the same time, operational == True is not necessarily deployment
succeeded, its more along the line of deployment validated, which may be
further testing passing like ostf, or more manual in the operator wants to
do more testing their own prior to changing the state.

As we adventure in to the LCM flow, we actually need status of each
component in addition of the general status of the cluster to determine the
proper course of action the on the next operation.

For example nova-compute
if the cluster is not operational, then we can provision compute nodes, and
have them enabled, or active in the scheduler automatically. However if the
cluster is operational, a new compute node must be disabled, or otherwise
blocked from the default scheduler until the node has received validation.
In this case the interpretation of operational is quite simple

For example ceph
Here we care less about the status of the cluster (slightly, this example
ignores ceph's impact on nova-compute), and more about the status of the
service. In the case that we deploy ceph-osd's when their are not replica
factor osd hosts online (3) the we can provision the OSD's similar to
nova-compute,  in that we can bring them all online and active and data
could be placed to them immediately (more or less). but if the ceph status
is operational, then we have to take a different action, the OSD's have to
be brought in disabled, and gradually(probably by the operator) have their
data weight increased so they don't clog the network with data peering
which causes the clients may woes.


> Thoughts, ideas?
>
>
> References:
>
> 1. https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status
>
>
> - romcheg
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


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

2016-03-11 Thread Andrew Woodward
...@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://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://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://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://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
>>>>
>>>> --
>>>> Mike Scherbakov
>>>> #mihgen
>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing 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
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> --
>>> Mike Scherbakov
>>> #mihgen
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> Mirantis, Inc.
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Mike Scherbakov
> #mihgen
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

2016-03-09 Thread Andrew Woodward
Today we had a sync up call and discussed this. To summarize

Attendees:
Aleksandr Didenko
Alex Schultz
Andrew Woodward
Alexey Shtokolov
Bartek Kupidura
Bogdan Dobrelya
Denis Egorenko
Ivan Berezovskiy
Kyrylo Galanov
Maksim Malchuk
Matthew Mosesohn
Max Yatsenko
Oleg Gelbukh
Oleksiy Molchanov
Petr Zhurba
Sergey Kolekonov
Sergey Vasilenko
Sergii Golovatiuk
Stanislav Makar
Stanislaw Bogatkin
Vladimir Eremin
Vladimir Kuklin

Issue: moving to puppet-openstack on master has exposed fuel-library to
breakage and there are many concerns about changes landing that can break
it.

Alex S. Proposed that we continue the course, and finish setting up Check
voting on the relevant puppet-openstack modules - The participants agreed
with this

Action: Sergii G & Aleksandra Fedorova will propose needed changes to
project-config to add tests

Issue: closing the regressions gap until fuel-ci votes on puppet-openstack
check

It was proposed that we invent a system that holds back the versions
nightly, and after completion of automated testing; It can automatically
move it forward.

Action: There was no consensus on this and should be discussed here further
on this thread.



On Sun, Mar 6, 2016 at 11:33 PM Dmitry Borodaenko <dborodae...@mirantis.com>
wrote:

> Aleksandra,
>
> Very good point on separating the concerns about integration tests for
> Fuel as a whole and verifying commits to a single component such as
> fuel-library. In theory, it could support the right balance between
> stable CI and up-to-date code, but only if we resolve the two remaining
> problems: one small and technical and the other large and social.
>
> You've already pointed out the first problem: update of fuel-library CI
> environment is not yet fully automated, and so the environment is liable
> to lag behind all involved components for days if not weeks.
>
> This by itself is simple enough, if labourous, to work around (update it
> manually every day, or after every successful BVT), but still leaves us
> with the problem of motivation.
>
> We've been discussing the CI duty for fuel-library integration with
> puppet-openstack since more than a month ago [0], and it has
> continuously failed to materialize. Within days of getting an action
> item in that IRC meeting to arrange it, Andrew Maksimov has responded
> privately that nobody in his team has time for this. And we all know
> what "I don't have time" actually means [1]. Two weeks later, we were
> ready to launch the integration and the question of CI duty came up
> again [2], with the same result.
>
> [0]
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-04-16.02.log.html#l-66
> [1]
> http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority
> [2]
> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-18-16.00.log.html#l-190
>
> Here we are two more weeks later, the integration is on, and the first
> reaction from fuel-library core reviewers is "we don't have time to deal
> with this, turn it back off right now". And I'm not just summarizing
> Vladimir's email, on Friday we had a long thread on an internal mailing
> list with exactly this in the subject line (my apologies, but my disgust
> at the fact that it was started behind closed doors drowns any qualms
> about dragging it back into the open).
>
> After we change Fuel CI to use fixed, most recent to have passed BVT,
> revisions of puppet-openstack modules, first thing that will happen is
> that BVT on Fuel ISO will start failing again, while fuel-library CI
> will continue to work. Without the pressure of failing commit
> verification CI, fuel-library developers will have even less incentive
> to keep fuel-library up to date with puppet-openstack (not to mention
> pro-actively reviewing puppet-openstack commits to catch potential
> regressions before they happen), and very soon Fuel QA team will get fed
> up with not having a stable ISO for the swarm test, and will demand that
> we go back to using fixed puppet-openstack revisions for the ISO, too.
>
> Both here and on the internal thread, many technical and organizational
> concerns were raised, and I'll get to them in a bit, but a concern
> without the will to resolve it is only an excuse, we won't get far if we
> don't want to make it work.
>
> So why don't fuel-library developers want to spend time on
> puppet-openstack integration?
>
> I see two dimensions to this problem. On one axis, there's the
> cost/benefit balance: how much work does it take, and what do we gain
> from doing it? On the other is the question of who benefits and who
> carries the costs?
>
> Without tracking HEAD of puppet-openstack in fuel-library, the primary
> cost is carried by puppet-openstack developers who maintain the upstr

[openstack-dev] [Fuel] FFE Tracking

2016-03-01 Thread Andrew Woodward
As FF quickly approaches (March 2) we have started posting feature freeze
exception requests.

If you would like to request an exception for your feature, please request
one in accordance with the guidelines [0], and include your estimate for
completion and risk at that time of completion. Also please add your
feature to the fuel meeting agenda [1] and we will review all of the
outstanding FFE requests on this Thursdays IRC meeting.

[0] https://wiki.openstack.org/wiki/FeatureFreeze
[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


[openstack-dev] [Fuel][FFE] Remove conflicting openstack module parts

2016-03-01 Thread Andrew Woodward
I'd like to request a feature freeze exception for the Remove conflicting
openstack module parts feature [0]

This is necessary to make the feature Decouple Fuel and OpenStack tasks
feature useful [1] , some of the patches are ready for review and some
still need to be written [2]

We need 2 - 3 weeks after FF to finish this feature. Risk of not delivering
it after 3 weeks is low.

[0]
https://blueprints.launchpad.net/fuel/+spec/fuel-remove-conflict-openstack
[1] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
[2]
https://review.openstack.org/#/q/topic:bp/fuel-remove-conflict-openstack,n,z
-- 

--

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


[openstack-dev] [Fuel][FFE] Decouple Fuel and OpenStack tasks

2016-03-01 Thread Andrew Woodward
I'd like to request a feature freeze exception for Decouple Fuel and
OpenStack tasks feature [0].

While the code change [1] is ready and usually passing CI we have too much
churn in the tasks currently which puts the patch set in conflict
constantly so it has to be rebased multiple times a day.

We need more review and feedback on the change, and a quiet period to merge
it

[0] https://blueprints.launchpad.net/fuel/+spec/fuel-openstack-tasks
[1] https://review.openstack.org/#/c/283332/
-- 

--

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


Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

2016-02-17 Thread Andrew Woodward
; versioned serializers for supported releases, which know how to convert
>> the only latest existing data to any of its supported previous versions.
>> - Decoupling we do by putting modules with its compositions to different
>> versioned /etc/puppet subdirectories. I'm not sure how do we decouple
>> Nailgun serializers though.
>> - Complexity is how we compose those modules / write logic of serializers.
>> - Duplication is puppet classes (and providers) with slightly different
>> call parameters from a version to version. Sometimes even not backwards
>> compatible. Probably same to the serializers?
>>
>> So, we're going to *increase complexity* by introducing
>> super-compositions for multi OpenStack releases. Not sure about what to
>> happen to the serializers, any volunteers to clarify an impact?. And the
>> Rules "allow" us to do so only in order to decrease either coupling or
>> shared state, which is not the case, AFAICT. Modules with compositions
>> are separated well by OpenStack versions, nothing to decrease. Might
>> that change to decrease a shared state? I'm not sure if it even applies
>> here. Puppet versioning shares nothing. Only Nailgun folks may know the
>> answer.
>>
>>
> I don't think we have to increase complexity if we properly structure
> fuel-library. I think we could also structure it in a way that can be
> tested in an automated fashion. I think we can come up with a set of rules
> for tasks and how to implement a new task that can reduce complexity and
> actually allow for code reuse.  If you take a look at our tasks today there
> is actually an excessive amount of duplication between tasks[0][1] around
> variable and configuration gathering before we even call the upstream
> OpenStack modules.  The tasks we have today are basically just undocumented
> freeform puppet that can only be fully tested via multiple deployment tests
> because of the lack of decent test coverage.  Additionally, we have no real
> way of testing deprecation between releases today because there's no formal
> api contract for modular tasks themselves.
>
> I would be interested in investigating a restructure of the tasks that
> might go something like
> 1) Restructure fuel-library tasks into a configuration
> generation/formatting method (extracting data from hiera/globals/etc) and
> the actual configuration application logic
> 2) For the configuration gathering items that we traditionally load up at
> the top of our tasks, we could investigate leveraging hiera for providing
> data to classes or structure into an osnailyfacter::config:: class.
> 2) Move the actual configuration application logic into an
> osnailyfacter::task:: method with a proper documented api contract
> with deprecation policy. These classes could use something like
> create_resources(...) to dynamically load the classes with the provided
> parameters to support the class api changes between upstream module
> versions.
> 3) Add release specific overrides into
> osnailyfacter::task where :: could be
> automatically included based on something like hiera('openstack_version')
>
> There are a few added benefits of restructuring the tasks into traditional
> puppet classes.
> 1) If we need to support any sort of traditional puppet master LCM for
> nodes, by moving the tasks into specific class we can actually just
> leverage our already written task code to ensure configurations.
> 2) Testability around idempotency as we can write beaker tests to be able
> to test deployment tasks for idempotency and deployment without having to
> stand up all the other pieces of fuel.  Similar to the Puppet OpenStack's
> puppet-openstack-integration[2] module.
> 3) Better defined separation and containment of release specific items so
> when we are moving forward.  It's much easier to remove n-X release as we
> could just 'find deployment/puppet/osnailyfacter/manifests/ -name 'kilo.pp'
> -delete'
>
> That being said, this would be a lot of work but it's mostly taking what
> we have today and reorganizing it rather than having to write things from
> scratch and providing some policy rules around structure of tasks.  I think
> in the long run we could benefit by being able to test fuel-library tasks
> with existing tools rather than continually having to rely on noop or
> actual deployment tests with nailgun/astute/isos/etc.  This is just a
> starting point for a conversation and I think we should have a serious
> discussion about this topic and not just dismiss it because it's hard or
> might add complexity.
>
>
> Thanks,
> -Alex
>
> [0]
> https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/glance/glance.pp#L3-L99
> [

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

2016-02-17 Thread Andrew Woodward
On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:

> > So we'll have tons of conditionals in composition layer, right? Even if
> > some puppet-openstack class have just one new parameter in new release,
> > then we'll have to write a conditional and duplicate class declaration.
> Or
> > write complex parameters hash definitions/merges and use
> > create_resources(). The more releases we want to support the more
> > complicated composition layer will become. That won't make contribution
> to
> > fuel-library easier and even can greatly reduce development speed. Also
> are
> > we going to add new features to stable releases using this workflow with
> > single composition layer?
>
> As I can see from an example composition [0], such code would be an
> unmaintainable burden for development and QA process. Next imagine a
> case for incompatible *providers* like network transformations - shall
> we put multiple if/case to the ruby providers as well?..
>

No, part of the point of reusing the current serializers from nailgun and
the current composition layer / fuel-library is exactly to avoid this kind
of issue. The other point is to take advantage of new features in the new
version of Fuel

The conditions needed in the composition layer are only to the underlying
puppet-openstack modules, which would be rolled back to version that
matches the openstack versions [a]

[a] https://github.com/xarses/fuel-library/blob/9-Kilo/deployment/Puppetfile

>
> That is not a way to go for a composition, sorry. While the idea may be
> doable, I agree, but perhaps another way.
>

Given the requirements to be able to use new features in fuel, with an
older version of OpenStack, what alternative would you propose?

>
> (tl;dr)
> By the way, this reminded me "The wrong abstraction" [1] article and
> discussion. I agree with the author and believe one should not group
> code (here it is versioned puppet modules & compositions) in a way which
> introduces abstractions (here a super-composition) with multiple
> if/else/case and hardcoded things to switch the execution flow based on
> version of things. Just keep code as is - partially duplicated by
> different releases in separate directories with separate modules and
> composition layers and think of better solutions please.
>
> There is also a nice comment: "...try to optimize my code around
> reducing state, coupling, complexity and code, in that order". I
> understood that like a set of "golden rules":
> - Make it coupled more tight to decrease (shared) state
> - Make it more complex to decrease coupling
> - Make it duplicated to decrease complexity (e.g. abstractions)
>
> (tl;dr, I mean it)
> So, bringing those here.
> - The shared state is perhaps the Nailgun's world view of all data and
> versioned serializers for supported releases, which know how to convert
> the only latest existing data to any of its supported previous versions.
> - Decoupling we do by putting modules with its compositions to different
> versioned /etc/puppet subdirectories. I'm not sure how do we decouple
> Nailgun serializers though.
> - Complexity is how we compose those modules / write logic of serializers.
> - Duplication is puppet classes (and providers) with slightly different
> call parameters from a version to version. Sometimes even not backwards
> compatible. Probably same to the serializers?
>
> So, we're going to *increase complexity* by introducing
> super-compositions for multi OpenStack releases. Not sure about what to
> happen to the serializers, any volunteers to clarify an impact?. And the
> Rules "allow" us to do so only in order to decrease either coupling or
> shared state, which is not the case, AFAICT. Modules with compositions
> are separated well by OpenStack versions, nothing to decrease. Might
> that change to decrease a shared state? I'm not sure if it even applies
> here. Puppet versioning shares nothing. Only Nailgun folks may know the
> answer.
>
> [0]
>
> https://review.openstack.org/#/c/281084/1/deployment/puppet/ceph/manifests/nova_compute.pp
> [1] https://news.ycombinator.com/item?id=11032296
>
> --
> 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
>
-- 

--

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


Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

2016-02-17 Thread Andrew Woodward
On Wed, Feb 17, 2016 at 8:38 AM Aleksandr Didenko <adide...@mirantis.com>
wrote:

> > This requires the loss of all of the features in the newer version of
> fuel since it relies on the older version of the serialized data from
> nailgun.
>
> Yes. But isn't it how "stable" branches are supposed to work? Introducing
> new features into "stable" branches will make them not so "stable", right?
> Even if these new features are introduced in composition layer or
> configuration data. just an example: network transformations in astute.yaml
> that are being translated into actual network configuration.
>

I think you may be confusing the OpenStack version fuel deploys and fuel
its self.
This is about keeping around older version(s) of OpenStack (most often the
most recent from master) and not dropping it during the development
process. This would allow for better switching during development (ie when
we need to move the default forward) and if we don't drop until after the
release, would allow for the usage of multiple versions of openstack.

> Yes, this is, in part,  about taking advantage of new fuel features on
> stable openstack releases, we are almost always behind and the previous
> release(s) supported this already.
>
> Introducing new features to stable releases will require full cycle of
> testing. So, basically, it will affect the whole development process.
>

This is not about introducing features to a stable fuel release, its about
taking advantage of fuel features with a older openstack release, the only
cycle we are working on is fuel.

We are almost always one or more releases behind openstack in supporting
features in openstack, this would rarely create an issue where the version
of openstack doesn't support what fuel is doing

Our development process already moves us through this process, when we
develop the next version of fuel, we stay on the same version of openstack
as the previous fuel release. We only cut forward very late in the cycle.
So we can simply support both through the end of the release cycle and then
decide if we are doping it in beginning of the next cycle



> > In addtion we currently don't allow for new clusters to be deployed this
> way.
>
> We can remove this restriction. Nailgun is able to serialize data for
> previous releases because that's how it supports adding new nodes to older
> environments after upgrade, so it should not be a problem.
>
> Regards,
> Alex
>
> On Fri, Feb 12, 2016 at 10:19 PM, Andrew Woodward <xar...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko <adide...@mirantis.com>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>> > So what is open? The composition layer.
>>>
>>> We can have different composition layers for every release and it's
>>> already implemented in releases - separate puppet modules/manifests dir for
>>> every release.
>>>
>>
>> This requires the loss of all of the features in the newer version of
>> fuel since it relies on the older version of the serialized data from
>> nailgun. In addtion we currently don't allow for new clusters to be
>> deployed this way.
>>
>>
>>>
>>> > Currently, we just abandon support for previous versions in the
>>> composition layer and leave them to only be monuments in the
>>> stable/ series branches for maintenance. If we instead started
>>> making changes (forwards or backwards that) change the calls based on the
>>> openstack version [5] then we would be able to change the calls based on
>>> then needs of that release, and the puppet-openstack modules we are working
>>> with.
>>>
>>> So we'll have tons of conditionals in composition layer, right? Even if
>>> some puppet-openstack class have just one new parameter in new release,
>>> then we'll have to write a conditional and duplicate class declaration. Or
>>> write complex parameters hash definitions/merges and use
>>> create_resources(). The more releases we want to support the more
>>> complicated composition layer will become. That won't make contribution to
>>> fuel-library easier and even can greatly reduce development speed. Also are
>>> we going to add new features to stable releases using this workflow with
>>> single composition layer?
>>>
>>> Yes, we need conditionals in the composition layer, we already need
>> these to no jam the gate when we switch between stable and master, we might
>> as well maintain them properly so that we can start running multiple
>> versions
>>
>> Yes, this is, in part,  about taking advant

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

2016-02-12 Thread Andrew Woodward
t CI, infra (required HW), acceptance
> testing, etc impact?
>

On average, two openstack releases would be supported the version that this
fuel is being developed for, and the prior stable openstack release. There
is an abnormal exception for Kilo. For 9 I would propose Kilo and Mitaka if
we want to keep it to just two.

ISO size, only one release should be bundled on the ISO, the other can
exist on the external package repos. the default release should be included
by default We would want to add parameter to pick this for during build if
someone wanted the other version

For the normal workflow (as an extension of how we function currently
anyway). We would gate the fuel cycle on the stable release and have a
non-voting basic test on master version. We would run regular BVT on both.
When we are ready to switch to the master release because of RC
availability or other high stability, then we would flip this. Stable would
become basic non-voting test and "master" (at this point new stable) would
get the gate


>
> Regards,
> Alex
>
>
>
> On Thu, Feb 11, 2016 at 6:57 AM, Andrew Woodward <xar...@gmail.com> wrote:
>
>> Right now master (targeting 9.0) is still deploying liberty and there is
>> active work going on to support both Kilo and Mitaka. On the review queue
>> are changes that would make fuel-library in-compatible with the prior
>> (liberty) openstack release. However I think if we extend a little bit of
>> effort we can keep some semblance of "support" while creating a pattern for
>> the Kilo support to continue to use. At the same time this pattern can help
>> us test parallel versions as we move through openstack releases and should
>> reduce occurrences of our CI freeze/merge parties
>>
>> What is this magic pattern? Well its already present, and all be it not
>> designed for this I think we could quickly make it work. We use the release
>> fixture already present in fuel. Originally designed to work for upgrades,
>> we could reuse this within the same fuel release to control various aspects
>> needed to deploy a separate openstack version.
>>
>> What we need to support multiple OpenStack versions:
>> 1) Packge repo's that contain the relevant bits. CHECK, this can be
>> toggled with a new release  [1][2]
>> 2) can point to different Puppet modules CHECK, also in toggled release
>>  [3]
>> 3) Composition layer that supports calls to different puppet-openstack
>> modules, WIP, it still needs work, but can be done [4]
>>
>> So what is open? The composition layer.
>>
>> Currently, we just abandon support for previous versions in the
>> composition layer and leave them to only be monuments in the
>> stable/ series branches for maintenance. If we instead started
>> making changes (forwards or backwards that) change the calls based on the
>> openstack version [5] then we would be able to change the calls based on
>> then needs of that release, and the puppet-openstack modules we are working
>> with.
>>
>> Given that we most of the time we would be supporting the previous
>> release (liberty) (which we should avoid dropping until after dev releases)
>> and the currently under development release (Mitaka), this will give us
>> some magical powers.
>>
>> Testing master while keeping stable. Given the ability to conditional
>> what source of openstack bits, which versions of manifests we can start
>> testing both master and keep health on stable. This would help accelerate
>> both fuel development and deploying and testing development versions of
>> openstack
>>
>> Deploying stable and upgrading later. Again given the ability to deploy
>> multiple OpenStack versions within the same Fuel version, teams focused on
>> upgrades can take advantage of the latest enhancements in fuel to work the
>> upgrade process more easily, as an added benefit this would eventually lead
>> to better support for end user upgrades too.
>>
>> Deploying older versions, in the odd case that we need to take advantage
>> of older OpenStack releases like in the case of Kilo with a newer version
>> of Fuel we can easily maintain that version too as we can keep the older
>> cases around in the composition layer with out adding much burden on the
>> other components.
>>
>> [1]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957
>> [2]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906
>>
>> [3]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371
>>
>> [4] htt

[openstack-dev] [fuel] Supporting multiple Openstack versions

2016-02-10 Thread Andrew Woodward
Right now master (targeting 9.0) is still deploying liberty and there is
active work going on to support both Kilo and Mitaka. On the review queue
are changes that would make fuel-library in-compatible with the prior
(liberty) openstack release. However I think if we extend a little bit of
effort we can keep some semblance of "support" while creating a pattern for
the Kilo support to continue to use. At the same time this pattern can help
us test parallel versions as we move through openstack releases and should
reduce occurrences of our CI freeze/merge parties

What is this magic pattern? Well its already present, and all be it not
designed for this I think we could quickly make it work. We use the release
fixture already present in fuel. Originally designed to work for upgrades,
we could reuse this within the same fuel release to control various aspects
needed to deploy a separate openstack version.

What we need to support multiple OpenStack versions:
1) Packge repo's that contain the relevant bits. CHECK, this can be toggled
with a new release  [1][2]
2) can point to different Puppet modules CHECK, also in toggled release  [3]
3) Composition layer that supports calls to different puppet-openstack
modules, WIP, it still needs work, but can be done [4]

So what is open? The composition layer.

Currently, we just abandon support for previous versions in the composition
layer and leave them to only be monuments in the stable/ series
branches for maintenance. If we instead started making changes (forwards or
backwards that) change the calls based on the openstack version [5] then we
would be able to change the calls based on then needs of that release, and
the puppet-openstack modules we are working with.

Given that we most of the time we would be supporting the previous release
(liberty) (which we should avoid dropping until after dev releases) and the
currently under development release (Mitaka), this will give us some
magical powers.

Testing master while keeping stable. Given the ability to conditional what
source of openstack bits, which versions of manifests we can start testing
both master and keep health on stable. This would help accelerate both fuel
development and deploying and testing development versions of openstack

Deploying stable and upgrading later. Again given the ability to deploy
multiple OpenStack versions within the same Fuel version, teams focused on
upgrades can take advantage of the latest enhancements in fuel to work the
upgrade process more easily, as an added benefit this would eventually lead
to better support for end user upgrades too.

Deploying older versions, in the odd case that we need to take advantage of
older OpenStack releases like in the case of Kilo with a newer version of
Fuel we can easily maintain that version too as we can keep the older cases
around in the composition layer with out adding much burden on the other
components.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957
[2]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906

[3]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371

[4] https://github.com/xarses/fuel-library/tree/9-Kilo

[5]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1948

-- 

--

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


Re: [openstack-dev] [fuel] Fuel Community ISO 8.0

2016-02-10 Thread Andrew Woodward
Was a bug ever filed for this? It's still not on the landing page

On Thu, Feb 4, 2016 at 4:19 AM Ivan Kolodyazhny <e...@e0ne.info> wrote:

> Thanks, Igor.
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
> On Thu, Feb 4, 2016 at 1:21 PM, Igor Belikov <ibeli...@mirantis.com>
> wrote:
>
>> Hi Ivan,
>>
>> I think this counts as a bug in our community page, thanks for noticing.
>> You can get 8.0 Community ISO using links in status dashboard on
>> https://ci.fuel-infra.org
>> --
>> Igor Belikov
>> Fuel CI Engineer
>> ibeli...@mirantis.com
>>
>> On 04 Feb 2016, at 13:53, Ivan Kolodyazhny <e...@e0ne.info> wrote:
>>
>> Hi team,
>>
>> I've tried to download Fuel Community ISO 8.0 from [1] and failed. We've
>> got 2 options there: the latest stable (7.0) and nightly build (9.0). Where
>> can I download 8.0 build?
>>
>> [1] https://www.fuel-infra.org/#fuelget
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>> __
>> OpenStack Development Mailing 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
>
-- 

--

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


Re: [openstack-dev] [Fuel][Plugins] Multi release packages

2016-02-10 Thread Andrew Woodward
th best regards,
> > Stan.
>
> >
> __
> > OpenStack Development Mailing 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
>
-- 

--

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


Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

2016-02-09 Thread Andrew Woodward
Unless we hope to gain some insight and specific testing by installing the
ISO on a bare-metal node (like UEFI), I'd propose that we stop testing
things that are well tested elsewhere (a given ISO produces a working fuel
master) and just focus on what we want to test in this environment.

Along this line, we cold

a) keep fuel masternode as a VM that is set up with access to the networks
with the BM nodes. We have a good set of tools to build the master node in
a VM already we can just re-use time

b) use cobbler to control PXE based ISO boot/install, then either create
new profiles in cobbler for various fuel nodes with different ISO or
replace the single download link. (Make sure you transfer the image over
HTTP as TFTP will be slow for such size. We have some tools and knowledge
around using cobbler as this is effectively what fuel does its self.

c) fuel on fuel, as an extension of b, we can just use cobbler on an
existing fuel node to provision another fuel node, either from ISO or even
it's own repo's (we just need to send a kickstart)

d) you can find servers with good BMC or DRAC that we can issue remote
mount commands to the virtual cd-rom

e) consider using live-cd approach (long implmentation). I've been asked
about supporting this in product where we start an environment with
live-cd, the master node may make it's own home and then it can be moved
off the live-cd when it's ready

On Tue, Feb 9, 2016 at 10:25 AM Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi,
>
> Ironic also supports running it as standalone service, w/o
> Keystone/Glance/Neutron/Nova etc integration, deploying images from HTTP
> links. Could that be an option too?
>
> BTW, there is already an official project under OpenStack Baremetal
> program called Bifrost [0] that, quoting, "automates the task of deploying
> a base image onto a set of known hardware using Ironic" by installing and
> configuring Ironic in standalone mode.
>
> [0] https://github.com/openstack/bifrost
>
> Cheers,
>
>
> On Tue, Feb 9, 2016 at 6:46 PM Dennis Dmitriev <ddmitr...@mirantis.com>
> wrote:
>
>> Hi all!
>>
>> To run system tests on CI on a daily basis using baremetal servers
>> instead of VMs, Fuel admin node also should be bootstrapped.
>>
>> There is no a simple way to mount an ISO with Fuel as a CDROM or USB
>> device to a baremetal server, so we choose the provisioning with PXE.
>
> It could be done in different ways:
>>
>> - Configure a libvirt bridge as dnsmasq/tftp server for admin/PXE network.
>>   Benefits: no additional services to be configured.
>>   Doubts: ISO should be mounted on the CI host (via fusefs?); a HTTP
>> or NFS server for basic provisioning should be started in the admin/PXE
>> network (on the CI host);
>>
>> - Start a VM that is connected to admin/PXE network, and configure
>> dnsmasq/tftp there.
>>   Benefits: no additional configuration on the CI host should be
>> performed
>>   Doubts: starting the PXE service becomes a little complicated
>>
>> - Use Ironic for manage baremetal nodes.
>>   Benefits: good support for different hardware, support for
>> provisioning from ISO 'out of the box'.
>>   Doubts: support for Ironic cannot be implemented in short terms,
>> and there should be performed additional investigations.
>>
>> My question is:  what other benefits or doubts I missed for first two
>> ways? Is there other ways to provision baremetal with Fuel that can be
>> automated in short terms?
>>
>> Thanks for any suggestions!
>>
>>
>> --
>> Regards,
>> Dennis Dmitriev
>> QA Engineer,
>> Mirantis Inc. http://www.mirantis.com
>> e-mail/jabber: dis.x...@gmail.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
>>
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
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


Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

2016-01-27 Thread Andrew Woodward
Simon, you should use the deployment_tasks.yaml interface (which will
likely eventually move to '*/tasks.yaml' (to mimic library) This uses the
same task system as granular deploy. you can set task ordering between
known tasks and roles names, in the case that they are not registered they
will simply be ignored.

The result will be that the engine will parse out the precise location for
tasks to run in the graph (you can run outside of the post-deployment with
them). In most cases, you will not need to specify precise ordering between
the plugins. I know there is the odd case that two components need to
modify the same parts, there are a couple of ways we can work this out, but
it ultimately will come down to a case-by case until we solidify the
config-db workflow

On Wed, Jan 27, 2016 at 5:45 AM Simon Pasquier <spasqu...@mirantis.com>
wrote:

> Hi,
>
> I see that tasks.yaml is going to be deprecated in the future MOS versions
> [1]. I've got one question regarding the ordering of tasks between
> different plugins.
> With tasks.yaml, it was possible to coordinate the execution of tasks
> between plugins without prior knowledge of which plugins were installed [2].
> For example, lets say we have 2 plugins: A and B. The plugins may or may
> not be installed in the same environment and the tasks execution should be:
> 1. Run task X for plugin A (if installed).
> 2. Run task Y for plugin B (if installed).
> 3. Run task Z for plugin A (if installed).
>
> Right now, we can set task priorities like:
>
> # tasks.yaml for plugin A
> - role: ['*']
>   stage: post_deployment/1000
>   type: puppet
>   parameters:
> puppet_manifest: puppet/manifests/task_X.pp
> puppet_modules: puppet/modules
>
> - role: ['*']
>   stage: post_deployment/3000
>   type: puppet
>   parameters:
> puppet_manifest: puppet/manifests/task_Z.pp
> puppet_modules: puppet/modules
>
> # tasks.yaml for plugin B
> - role: ['*']
>   stage: post_deployment/2000
>   type: puppet
>   parameters:
> puppet_manifest: puppet/manifests/task_Y.pp
> puppet_modules: puppet/modules
>
> How would it be handled without tasks.yaml?
>
> Regards,
> Simon
>
> [1] https://review.openstack.org/#/c/271417/
> [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [Fuel] Wipe of the nodes' disks

2016-01-07 Thread Andrew Woodward
On Tue, Dec 29, 2015 at 5:35 AM Sergii Golovatiuk <sgolovat...@mirantis.com>
wrote:

> Hi,
>
> Let me comment inline.
>
>
> On Mon, Dec 28, 2015 at 7:06 PM, Andrew Woodward <xar...@gmail.com> wrote:
>
>> In order to ensure that LVM can be configured as desired, its necessary
>> to purge them and then reboot the node, otherwise the partitioning commands
>> will most likely fail on the next attempt as they will be initialized
>> before we can start partitioning the node. Hence, when a node is removed
>> from the environment, it is supposed to have this data destroyed. Since
>> it's a running system, the most effective way was to blast the first 1Mb of
>> each partition. (with out many more reboots)
>>
>> As to the fallback to SSH, there are two times we use this process, with
>> the node reboot (after cobbler/IBP finishes), and with the wipe as we are
>> discussing here. These are for the odd occurrences of the nodes failing to
>> restart after the MCO command. I don't think anyone has had much success
>> trying to figure out why this occurs, but I've seen nodes get stuck in
>> provisioning and remove in multiple environments using 6.1 where they
>> managed to break the SSH Fallback. It would occur around 1/20 nodes
>> seemingly randomly. So with the SSH fallback I nearly never see the failure
>> in node reboot.
>>
>
> If we talk about 6.1-7.0 release there shouldn't be any problems with mco
> reboot. SSH fallback must be deprecated at all.
>

As I noted, I've see several 6.1 deployments where it was needed, I'd
consider it still very much in use. In other cases it might be necessary to
attempt to deal with a node who's MCO agent is dead, IMO they should be
kept.


>>
>
>>
>
>>
>
>> On Thu, Dec 24, 2015 at 6:28 AM Alex Schultz <aschu...@mirantis.com>
>> wrote:
>>
>>> On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov
>>> <asvechni...@mirantis.com> wrote:
>>> > Hi,
>>> > We have faced the issue that nodes' disks are wiped after stop
>>> deployment.
>>> > It occurs due to the logic of nodes removing (this is old logic and
>>> it's not
>>> > actual already as I understand). This logic contains step which calls
>>> > erase_node[0], also there is another method with wipe of disks [1].
>>> AFAIK it
>>> > was needed for smooth cobbler provision and ensure that nodes will not
>>> be
>>> > booted from disk when it shouldn't. Instead of cobbler we use IBP from
>>> > fuel-agent where current partition table is wiped before provision
>>> stage.
>>> > And use disks wiping for insurance that nodes will not booted from disk
>>> > doesn't seem good solution. I want to propose not to wipe disks and
>>> simply
>>> > unset bootable flag from node disks.
>>>
>>
> Disks must be wiped as boot flag doesn't guarantee anything. If bootlag is
> not set, BIOS will ignore ignore the device in boot-order. More over, 2
> partitions may have bootflag or operator may set to skip boot-order in BIOS.
>
> >
>>> > Please share your thoughts. Perhaps some other components use the fact
>>> that
>>> > disks are wiped after node removing or stop deployment. If it's so,
>>> then
>>> > please tell about it.
>>> >
>>> > [0]
>>> >
>>> https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137
>>> > [1]
>>> >
>>> https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb
>>> >
>>>
>>> I thought the erase_node[0] mcollective action was the process that
>>> cleared a node's disks after their removal from an environment. When
>>> do we use the ssh_erase_nodes?  Is it a fall back mechanism if the
>>> mcollective fails?  My understanding on the history is based around
>>> needing to have the partitions and data wiped so that the LVM groups
>>> and other partition information does not interfere with the
>>> installation process the next time the node is provisioned.  That
>>> might have been a side effect of cobbler and we should test if it's
>>> still an issue for IBP.
>>>
>>
> Since we do not use classical provision anymore, we have mco connection
> all the time. During IBP we have it as part of bootstrap, after reboot, mco
> is still present so all actions should be done via mco.
>
>
>>
>>>
>>> Thanks,
>>> -Alex
>>>
>>

Re: [openstack-dev] [Fuel] Wipe of the nodes' disks

2015-12-28 Thread Andrew Woodward
In order to ensure that LVM can be configured as desired, its necessary to
purge them and then reboot the node, otherwise the partitioning commands
will most likely fail on the next attempt as they will be initialized
before we can start partitioning the node. Hence, when a node is removed
from the environment, it is supposed to have this data destroyed. Since
it's a running system, the most effective way was to blast the first 1Mb of
each partition. (with out many more reboots)

As to the fallback to SSH, there are two times we use this process, with
the node reboot (after cobbler/IBP finishes), and with the wipe as we are
discussing here. These are for the odd occurrences of the nodes failing to
restart after the MCO command. I don't think anyone has had much success
trying to figure out why this occurs, but I've seen nodes get stuck in
provisioning and remove in multiple environments using 6.1 where they
managed to break the SSH Fallback. It would occur around 1/20 nodes
seemingly randomly. So with the SSH fallback I nearly never see the failure
in node reboot

On Thu, Dec 24, 2015 at 6:28 AM Alex Schultz <aschu...@mirantis.com> wrote:

> On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov
> <asvechni...@mirantis.com> wrote:
> > Hi,
> > We have faced the issue that nodes' disks are wiped after stop
> deployment.
> > It occurs due to the logic of nodes removing (this is old logic and it's
> not
> > actual already as I understand). This logic contains step which calls
> > erase_node[0], also there is another method with wipe of disks [1].
> AFAIK it
> > was needed for smooth cobbler provision and ensure that nodes will not be
> > booted from disk when it shouldn't. Instead of cobbler we use IBP from
> > fuel-agent where current partition table is wiped before provision stage.
> > And use disks wiping for insurance that nodes will not booted from disk
> > doesn't seem good solution. I want to propose not to wipe disks and
> simply
> > unset bootable flag from node disks.
> >
> > Please share your thoughts. Perhaps some other components use the fact
> that
> > disks are wiped after node removing or stop deployment. If it's so, then
> > please tell about it.
> >
> > [0]
> >
> https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137
> > [1]
> >
> https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb
> >
>
> I thought the erase_node[0] mcollective action was the process that
> cleared a node's disks after their removal from an environment. When
> do we use the ssh_erase_nodes?  Is it a fall back mechanism if the
> mcollective fails?  My understanding on the history is based around
> needing to have the partitions and data wiped so that the LVM groups
> and other partition information does not interfere with the
> installation process the next time the node is provisioned.  That
> might have been a side effect of cobbler and we should test if it's
> still an issue for IBP.
>
>
> Thanks,
> -Alex
>
> [0]
> https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb
>
> > Best regards,
> > Svechnikov Artur
> >
> >
> __
> > OpenStack Development Mailing 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
>
-- 

--

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


Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-28 Thread Andrew Woodward
On Mon, Dec 28, 2015 at 1:13 AM Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:

> On 23.12.2015 18:50, Matthew Mosesohn wrote:
> > I agree. As far as I remember, rabbit needs fqdns to work and map
> > correctly. I think it means we should disable the ability to move the
> > internal messaging network role in order to fix this bug until we can
> > add extra dns entries per network role (or at least addr)
>
> For DNS resolve, we could use SRV [0] records perhaps.
> Although, nodes rely on /etc/hosts instead, AFAIK.
>
> So we could as well do net-template-based FQDNs instead, like
> messaging-node*-domain.local 1.2.3.4
> corosync-node*-domain.local 5.6.7.8
> database-node*-domain.local 9.10.11.12
>
> and rely on *these* FQDNS instead.
>

This is probably going to be the best way to work out this issue since we
can move all of these services around as it is. I would attempt to remove
the node identifier if possible so the names aren't wrong if the service is
moved between nodes.


> [0] https://en.wikipedia.org/wiki/SRV_record
>
> >
> > On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <amaksi...@mirantis.com
> > <mailto:amaksi...@mirantis.com>> wrote:
> >
> > Hi Kirill,
> >
> > I don't think we can give up on using fqdn node names for RabbitMQ
> > because we need to support TLS in the future.
> >
> > Thanks,
> > Andrey Maximov
> > Fuel Project Manager
> >
> > On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov
> > <kgala...@mirantis.com <mailto:kgala...@mirantis.com>> wrote:
> >
> > Hello,
> >
> > I would like to start discussion regarding the issue we have
> > discovered recently [1].
> >
> > In a nutshell, if RabbitMQ is configured to run in separate
> > mgmt/messaging network it fails on building cluster.
> > While RabbitMQ is managed by Pacemaker and OCF script, the
> > cluster is built using FQDN. Apparently, FQDN resolves to admin
> > network which is different in this particular case.
> > As a result, RabbitMQ on secondary controller node fails to join
> > to primary controller node.
> >
> > I can suggest two ways to tackle the issue: one is pretty
> > simple, while other is not.
> >
> > The first way is to accept by design using admin network for
> > RabbitMQ internal communication between controller nodes.
> >
> > The second way is to dig into pacemaker
> > and RabbitMQ reconfiguration. Since it requires to refuse from
> > using common fqdn/node names, this approach can be argued.
> >
> >
> > --
> > [1] https://bugs.launchpad.net/fuel/+bug/1528707
> >
> > Best regards,
> > Kyrylo
> >
> >
>  __
> > 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://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,
> 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
>
-- 

--

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


[openstack-dev] [Fuel] Spec policy

2015-12-23 Thread Andrew Woodward
We've been developing following the spec and blueprint approach for a while
and have even been firm with requiring "blueprint or bug" on commit
messages for a while now. However we have been more than neglecting the
specification ('spec') process. Quite often we see that a spec languishes
on review, sometimes its not reviewed, others it's not updated by the
other. In the end, its common that code lands in the component prior to the
spec being completed and merged its self. Furthermore this results in late
management of the blueprints in launchpad.

I propose that we start enforcing the implied spec requirement. At the same
time, we should be managing the blueprint status along with the spec so
that reviewers can quickly identify the status of the blueprint. Lastly, we
will need to clarify the role of the spec on the wiki as it's currently not
clear.


-- 

--

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


[openstack-dev] [Fuel] Meeting Schedule for Dec / Jan and Holidays

2015-12-17 Thread Andrew Woodward
As we discussed in the meeting today, the normal meeting schedule of every
Thursday overlaps with a number of holiday times

Dec 24, Christmas Eve
Dec 31, New Years Eve
Jan 7, Russian Orthodox Christmas day // Part of New Years rest

We agreed for the following schedule.

Dec 24 will be moved to Dec 23.
Dec 31 is canceled.
Jan 7 is canceled.
Jan 14, return to our normal schedule.

For the Dec 23rd meeting, I will try look to see if there is an opening in
the #openstack-meeting* rooms for us in our regular time slot, otherwise we
will conduct the meeting on #fuel-dev

-- 

--

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


Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

2015-12-07 Thread Andrew Woodward
I'd have to say that this is expected behavior. I'm not sure what you would
hope to prohibit when these kinds of things are necessary for the
deployment. We also can't prohibit this from being done in a plugin, this
is what the plugin verification is supposed to help combat. If you just go
download a random puppet manifest // script // etc... from the internet,
how do you ensure that it didn't install a root-kit.

On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin <ekore...@mirantis.com> wrote:

> As far as I know this feature is planned for the next releases.
>
> But I think the main problem is: it's not obvious that just by installing
> a plugin, even without enabling the plugin in Fuel user could break or
> somehow alter already existing environments.  It could be done by malicious
> attacker who could compromise plugin or just unintentionally with some bug
> in the plugin code.
>
> Unfortunately, by installing some plugin a user jeopardizes his existing
> environments. And I think we should at least document these risks.
>
>
> On 07.12.2015 19:52, Javeria Khan wrote:
>
> My two cents. It would be useful to have a role that could execute on the
> Fuel Master host itself rather than a container.
>
> --
> Javeria
> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" <m...@romcheg.me> wrote:
>
>> Alexey,
>>
>> thank you for bringing this up. IMO discussing security problems is
>> better to be done in a special kind of Launchpad bugs.
>>
>> - romcheg
>>
>>
>> > 7 груд. 2015 р. о 17:36 Alexey Elagin <aela...@mirantis.com>
>> написав(ла):
>> >
>> > Hello all,
>> >
>> > We have a security problem in Fuel 7.0. It's related to plugin
>> > development and allows to execute code in mcollective docker container
>> > on Fuel master node. Any fuel plugin may contains a yaml file with
>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
>> > an ability to run some code on node with role "master". It's also
>> > possible to connect to any target node via ssh without a password from
>> > within the container.
>> >
>> > As i understood, it was made to simplify some deployment cases. I see
>> > some steps for resolving this situation:
>> > 1. Fuel team should disallow
>> > execution of any puppet manifests or bash code on nodes with master
>> > role.
>> > 2. Append the Fuel documentation. Notify users about this
>> > security issue.
>> >
>> > What do you think about it? What deployment cases which require
>> > execution of code on role "master" do you know?
>> >
>> > --
>> > Best regards,
>> > Alexey
>> > Deployment Engineer
>> > Mirantis, Inc
>> > Cell: +7 (968) 880 2288
>> > Skype: shikelbober
>> > Slack: aelagin
>> > mailto:aela...@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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Eugene Korekin
> Partner Enablement Team Deployment Engineer
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

2015-12-07 Thread Andrew Woodward
Guys, we can not create any limitations on plugins ability to do things
that we allow with the 'core' system. We need to be lees strict and more
flexible with the plugin framework not constrict it randomly because there
is a way to execute dangerous code. We are in the business of buiding,
deploying, maintaining and erasing nodes. Everything we do,  want to do,
and want other to do is 'dangerous' we need to limit a users risk with
verification of plugins not creating rules that limit functions plugins
have access to.

On Mon, Dec 7, 2015 at 11:36 AM Oleg Gelbukh <ogelb...@mirantis.com> wrote:

> +1 to Eugene here. Eventually we will need to more strictly define Plugins
> framework and SDK and limit possible actions to the set of supported ones.
> This is required not only for security and/or stability reasons, but for
> upgrade purposes as well.
>
> On the other hand, we need to retain certain flexibility of deployment.
> That could be achieved by turning the 'core' components into pluggable
> options, and reducing the 'core'  to the set of replaceable plugins shipped
> with the reference architecture. This will eliminate the need for many of
> the hack used nowadays in plugins to override default behaviours.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Mon, Dec 7, 2015 at 9:29 PM, Eugene Korekin <ekore...@mirantis.com>
> wrote:
>
>> Stas,
>>
>> I fear that often even developer of a code cannot verify his own code
>> completely, let alone some third-party validation teams. Does the ability
>> to strictly limit plugin actions by the list of intended environments looks
>> nonviable to you?
>>
>>
>>
>> On 07.12.2015 20:38, Stanislaw Bogatkin wrote:
>>
>> +1 to Andrew. Plugins created for run some code and plugin verification
>> is the source of trust there.
>>
>> On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward <xar...@gmail.com> wrote:
>>
>>> I'd have to say that this is expected behavior. I'm not sure what you
>>> would hope to prohibit when these kinds of things are necessary for the
>>> deployment. We also can't prohibit this from being done in a plugin, this
>>> is what the plugin verification is supposed to help combat. If you just go
>>> download a random puppet manifest // script // etc... from the internet,
>>> how do you ensure that it didn't install a root-kit.
>>>
>>> On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin <ekore...@mirantis.com>
>>> wrote:
>>>
>>>> As far as I know this feature is planned for the next releases.
>>>>
>>>> But I think the main problem is: it's not obvious that just by
>>>> installing a plugin, even without enabling the plugin in Fuel user could
>>>> break or somehow alter already existing environments.  It could be done by
>>>> malicious attacker who could compromise plugin or just unintentionally with
>>>> some bug in the plugin code.
>>>>
>>>> Unfortunately, by installing some plugin a user jeopardizes his
>>>> existing environments. And I think we should at least document these risks.
>>>>
>>>>
>>>> On 07.12.2015 19:52, Javeria Khan wrote:
>>>>
>>>> My two cents. It would be useful to have a role that could execute on
>>>> the Fuel Master host itself rather than a container.
>>>>
>>>> --
>>>> Javeria
>>>> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko" < <m...@romcheg.me>
>>>> m...@romcheg.me> wrote:
>>>>
>>>>> Alexey,
>>>>>
>>>>> thank you for bringing this up. IMO discussing security problems is
>>>>> better to be done in a special kind of Launchpad bugs.
>>>>>
>>>>> - romcheg
>>>>>
>>>>>
>>>>> > 7 груд. 2015 р. о 17:36 Alexey Elagin <aela...@mirantis.com>
>>>>> написав(ла):
>>>>> >
>>>>> > Hello all,
>>>>> >
>>>>> > We have a security problem in Fuel 7.0. It's related to plugin
>>>>> > development and allows to execute code in mcollective docker
>>>>> container
>>>>> > on Fuel master node. Any fuel plugin may contains a yaml file with
>>>>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
>>>>> > an ability to run some code on node with role "master". It's also
>>>>> > possible to connect to any target node via ssh without a password
>>>>> from
>>&g

Re: [openstack-dev] [Fuel] Patch size limit

2015-12-07 Thread Andrew Woodward
eviewGuidelines
>> > [3]
>> >
>> http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07831.html
>> > [4] http://docs.openstack.org/infra/manual/developers.html#peer-review
>> >
>> >
>> > Best regards,
>> > Andrey Tykhonov (tkhno)
>> >
>> >
>> >
>> __
>> > 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://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
>
-- 

--

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


Re: [openstack-dev] [puppet] [release] Puppet OpenStack 7.0.0 Liberty (_independent)

2015-11-26 Thread Andrew Woodward
Fantastic to hear, good work guys.

On Thu, Nov 26, 2015, 3:01 PM David Moreau Simard <d...@redhat.com> wrote:

> Awesome !
>
> Congratulations to everyone involved in the release of the most
> popular deloyment method [1] :)
> The new acceptance and integration tests make this rock solid, too !
>
> [1]:
> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
>
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Thu, Nov 26, 2015 at 9:12 AM, Emilien Macchi <emil...@redhat.com>
> wrote:
> > Puppet OpenStack community is very proud to announce the release of 22
> > modules:
> >
> > puppet-aodh 7.0.0
> > puppet-ceilometer 7.0.0
> > puppet-cinder 7.0.0
> > puppet-designate 7.0.0
> > puppet-glance 7.0.0
> > puppet-gnocchi 7.0.0
> > puppet-heat 7.0.0
> > puppet-horizon 7.0.0
> > puppet-ironic 7.0.0
> > puppet-keystone 7.0.0
> > puppet-manila 7.0.0
> > puppet-murano 7.0.0
> > puppet-neutron 7.0.0
> > puppet-nova 7.0.0
> > puppet-openstacklib 7.0.0
> > puppet-openstack_extras 7.0.0
> > puppet-sahara 7.0.0
> > puppet-swift 7.0.0
> > puppet-tempest 7.0.0
> > puppet-trove 7.0.0
> > puppet-tuskar 7.0.0
> > puppet-vswitch 3.0.0
> >
> > For more details about the release, you can visit:
> > https://wiki.openstack.org/wiki/Puppet/releases
> > https://forge.puppetlabs.com/openstack
> >
> > Here are some interesting numbers [1]:
> >
> > Contributors during Kilo cycle: 91
> > Contributors during Liberty cycle: 108
> >
> > Commits during Kilo cycle: 730
> > Commits during Liberty cycle: 1201
> >
> > LOC during Kilo cycle: 67104
> > LOC during Liberty cycle: 93448
> >
> > [1] Sources: http://stackalytics.openstack.org
> >
> > Thank you to the Puppet OpenStack community to make it happen,
> > Also big kudos to other teams, specially OpenStack Infra, Tempest and
> > Packaging folks who never hesitate to help us.
> > --
> > Emilien Macchi
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

2015-11-25 Thread Andrew Woodward

IMO, removing the docker containers is a mistake v.s. fixing them and using
them properly. They provide an isolation that is necessary (and that we
mangle) to make services portable and scaleable. We really should sit down
and document how we really want all of the services to interact before we
rip the containers out.

I agree, the way we use containers now still is quite wrong, and brings us
some negative value, but I'm not sold on stripping them out now just
because they no longer bring the same upgrades value as before.


My opinion aside, we are rushing into this far to late in the feature
cycle. Prior to moving forward with this, we need a good QA plan, the spec
is quite light on that and must receive review and approval from QA. This
needs to include an actual testing plan.

>From the implementation side, we are pushing up against the FF deadline. We
need to document what our time objectives are for this and when we will no
longer consider this for 8.0.

Lastly, for those that are +1 on the thread here, please review and comment
on the spec, It's received almost no attention for something with such a
large impact.

On Tue, Nov 24, 2015 at 4:58 PM Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> The status is as follows:
>
> 1) Fuel-main [1] and fuel-library [2] patches can deploy the master node
> w/o docker containers
> 2) I've not built experimental ISO yet (have been testing and debugging
> manually)
> 3) There are still some flaws (need better formatting, etc.)
> 4) Plan for tomorrow is to build experimental ISO and to begin fixing
> system tests and fix the spec.
>
> [1] https://review.openstack.org/#/c/248649
> [2] https://review.openstack.org/#/c/248650
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Colleagues,
>>
>> I've started working on the change. Here are two patches (fuel-main [1]
>> and fuel-library [2]). They are not ready to review (still does not work
>> and under active development). Changes are not going to be huge. Here is a
>> spec [3]. Will keep the status up to date in this ML thread.
>>
>>
>> [1] https://review.openstack.org/#/c/248649
>> [2] https://review.openstack.org/#/c/248650
>> [3] https://review.openstack.org/#/c/248814
>>
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy <
>> amarets...@mirantis.com> wrote:
>>
>>>
>>>
>>> On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya <bdobre...@mirantis.com
>>> > wrote:
>>>
>>>> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
>>>> > Hi all,
>>>> >
>>>> > as you know, Rally runs inside docker on Fuel master node, so docker
>>>> > removal (good improvement) is a problem for Rally users.
>>>> >
>>>> > To solve this, I'm planning to make native Rally installation on Fuel
>>>> > master node that is running on CentOS 7,
>>>> > and then make a step-by-step instruction how to make this
>>>> installation.
>>>> >
>>>> > So I hope docker removal will not make issues for Rally users.
>>>>
>>>> I believe the most backwards compatible scenario is to keep the docker
>>>> installed while removing the fuel-* docker things back to the host OS.
>>>> So nothing would prevent user from pulling and running whichever docker
>>>> containers he wants to put on the Fuel master node. Makes sense?
>>>>
>>>>
>>> Sounds good
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
-- 

--

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


[openstack-dev] [puppet] [ceph] Puppet Ceph CI

2015-11-23 Thread Andrew Woodward
I think I have a good lead on the recent failures in openstack / swift /
radosgw integration component that we have since disabled. It looks like
there is a oslo.config version upgrade conflict in the Juno repo we where
using for CentOS. I think moving to Kilo will help sort this out, but at
the same time I think it would be prudent to separate the Ceph v.s.
OpenStack integration into separate jobs so that we have a better idea of
which is a problem. If there is census for this, I'd need some direction /
help, as well as set them up as non-voting for now.

Looking into this I also found that the only place that we do integration
any of the cephx logic was in the same test so we will need to create a
component for it in the ceph integration as well as use it in the OpenStack
side.

Lastly un-winding the integration failure seemed overly complex. Is there a
way that we can correlate the test status inside the job at a high level
besides the entire job passed / failed without breaking them into separate
jobs?
-- 

--

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


Re: [openstack-dev] [Fuel] Number of IP addresses in a public network

2015-11-19 Thread Andrew Woodward
//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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


Re: [openstack-dev] [fuel] Add Fuel to OpenStack projects: status update

2015-11-11 Thread Andrew Woodward
; to fully align our CI with OpenStack Infra.
> >
> > [2]
> http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2015-11-10.log.html#t2015-11-10T21:03:34
> >
> > Still, I believe that making this a hard requirement for Fuel's
> > acceptance into Big Tent would be one step too far down a slippery slope
> > into a whole new vat of worms. Objective inclusion criteria such as
> > Project Requirements and Project Testing Interface are there to protect
> > OpenStack contributors from real and perceived favouritism. Declaring,
> > especially selectively, that meeting these criteria may be insufficient,
> > takes all the objectivity out of them. Fortunately, Jim did not insist
> > on making progress with Fuel multi-node tests a hard requirement and
> > confirmed that he will not block our proposal based on that. He still
> > wants us to finish setting up gates, though, fair is fair.
> >
> > Finally, the odd one out was the objection from Dean Troyer: "re Fuel,
> > I'm just not convinced it fits OpenStack's mission... we generally have
> > stayed away from being a distro". It was quickly dismissed by other
> > participants, but Dean still abstained, putting us one more vote short
> > of approval. I think this serves to illustrate that many prominent
> > members of OpenStack community still view Fuel as an OpenStack
> > distribution, even after the two years we've spent establishing Fuel as
> > a toolset for deployment and operation of OpenStack environments,
> > decoupled from whatever Linux and OpenStack distributions you choose to
> > deploy with it. I can only hope that Fuel is accepted into Big Tent and
> > more distributions are encouraged to use it, so that this particular
> > confusion is finally laid to rest.
> >
> > Some of you may be surprised by how much scrutiny Fuel is facing when
> > compared to smaller and younger projects. In a way, Fuel is a victim of
> > its own success: we've got so many components and such an extensive and
> > diverse CI coverage that bringing all that into compliance with The
> > OpenStack Way is really that much more work than it is for a typical new
> > project with just one git repo and a handful of unit test jobs. Don't be
> > discouraged by this additional delay: Fuel is big and has a lot of value
> > to bring into OpenStack on many levels, Technical Committee is
> > appreciative of that and supportive of our efforts, additional scrutiny
> > is there because they want to get this right. Lets prove that their
> > trust in us is not misplaced.
> >
> > --
> > Dmitry Borodaenko
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
--
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


Re: [openstack-dev] [puppet] [ceph] puppet-ceph working session

2015-10-27 Thread Andrew Woodward
Thanks,
I've added it to the puppet-code session etherpad.

https://etherpad.openstack.org/p/HND-puppet-code


On Wed, Oct 28, 2015 at 12:00 PM Emilien Macchi <emilien.mac...@gmail.com>
wrote:

>
>
> On 10/28/2015 11:09 AM, Andrew Woodward wrote:
> > For those of you interested at the summit, I'd like to get together at
> > some point and discuss / resolve issues on CI, and then talk about
> > release and possible roadmap.
> >
> > Let's pick a time so that we can meet together on this.
>
> Good idea, I suggest we meet in the Puppet work sessions, so we get
> attention from the team.
>
> Thanks,
>
> Emilien
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

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


[openstack-dev] [puppet] [ceph] puppet-ceph working session

2015-10-27 Thread Andrew Woodward
For those of you interested at the summit, I'd like to get together at
some point and discuss / resolve issues on CI, and then talk about
release and possible roadmap.

Let's pick a time so that we can meet together on this.

Andrew

__
OpenStack Development Mailing 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] Assigning VIPs on network config serialization

2015-10-19 Thread Andrew Woodward
__
> > OpenStack Development Mailing 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
>
-- 
--
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


Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins

2015-10-16 Thread Andrew Woodward
We have already discussed this to be a result of describing data driven
testing, untill this spec is completed there is little sense to remove all
of these since fuel-qa is 100% required to operate this way. In the interim
we should just specify the appropriate SME with the MAINTAINERS file.

On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <sgolovat...@mirantis.com>
wrote:

> Tests should be in plugin
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <spasqu...@mirantis.com>
> wrote:
>
>> Hello Alexey,
>>
>> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin <aela...@mirantis.com>
>> wrote:
>>
>>> Hello Simon!
>>>
>>> We are going to remove plugins' functional tests from fuel-qa because
>>> this tests don't use for our plugins CI process.
>>>
>>
>> And where are the existing tests going to be stored then?
>>
>> Thanks,
>> Simon
>>
>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>
-- 

--

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


Re: [openstack-dev] FW: [Fuel] 8.0 Region name support / Multi-DC

2015-10-08 Thread Andrew Woodward
ed to comment here.
>>>
>>>
>>>
>>> Regarding specifying region names in UI, is it possible to specify
>>> region names in API?  And (apologies for my ignorance on this one) what is
>>> the relative equivalence to environments in Fuel (e.g. 1 environment : many
>>> regions, 1 environment == 1 region)?
>>>
>>>
>>>
>>> *From:* Roman Sokolkov [mailto:rsokol...@mirantis.com]
>>> *Sent:* Friday, October 02, 2015 5:26 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev@lists.openstack.org>
>>> *Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC
>>>
>>>
>>>
>>> Folks,
>>>
>>>
>>>
>>> i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
>>> support.
>>>
>>>
>>>
>>> My ask is about tiny(but useful) feature: give user ability to *specify
>>> Region name in UI.*
>>>
>>>
>>>
>>> Region name is already in every puppet module, so we just need to add
>>> this to UI.
>>>
>>>
>>>
>>> Do we have smth already?
>>>
>>>
>>>
>>> More general question: What are our plans in regards Multi-DC?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> --
>>>
>>> Roman Sokolkov,
>>>
>>> Deployment Engineer,
>>>
>>> Mirantis, Inc.
>>> Skype rsokolkov,
>>> rsokol...@mirantis.com
>>>
>>> --
>>>
>>> Chris Clason
>>>
>>> Director of Architecture
>>>
>>> ccla...@mirantis.com
>>>
>>> Mobile: +1.408.409.0295
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Roman Sokolkov,
>> Deployment Engineer,
>> Mirantis, Inc.
>> Skype rsokolkov,
>> rsokol...@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
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
-- 
--
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


Re: [openstack-dev] [fuel] Problems with mcollective offline nodes

2015-10-05 Thread Andrew Woodward
[ Was: Re: [openstack-dev] OpenStack-dev Digest, Vol 41, Issue 49]

Santosh Parihar,

This implies that the nodes are (in order of most to least likely):
a) currently offline
b) un-accessible from the fuel master node
c) the mcollective agent is not running on them
d) rabbitmq on the fuel node (rabbitmq container) is not functioning
properly

Fuel uses mcollective (MCO) to issue commands to remote nodes.
You can start by pining the nodes, from the CLI you can issue `fuel node`
and it will show the nodes id, and IP address. From there you can use `mco
ping` to determine if mcollective can talk to the nodes. From there you can
triage individual nodes connectivity, or restart them. Alternately you can
investigate and restart the mcollective and or rabbitmq containers.

We are also on IRC #Fuel on irc.freenode.net. We have alot of the European
folks on around when you posted this message so you can drop a line in
there if you would like to get some more interactive help.

-
Andrew
Fuel Community.

On Mon, Oct 5, 2015 at 1:55 AM santosh parihar <santosh.parih...@gmail.com>
wrote:

> Topic - Fuel
>
> Hi,
>
> My deployment is failing beacuse of following reason :
>
> Verification failed.
> Method verify_networks. Network verification not avaliable because nodes
> ["3", "4", "6", "7"] not avaliable via mcollective. Inspect Astute logs for
> the details
>
> anybody can help here ?
>
> --

--

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


Re: [openstack-dev] [puppet] [infra] split integration jobs

2015-09-30 Thread Andrew Woodward
Emillien,

What image is being used to spawn the image? We see 300 sec as a good
timeout time in fuel with a cirros image. The time can usually be
substantially cut if the image is of any size using ceph for ephemeral...

On Wed, Sep 30, 2015 at 4:37 PM Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2015-09-30 17:14:27 -0400 (-0400), Emilien Macchi wrote:
> [...]
> > I like #3 but we are going to consume more CI resources (that's why I
> > put [infra] tag).
> [...]
>
> I don't think adding one more job is going to put a strain on our
> available resources. In fact it consumes just about as much to run a
> single job twice as long since we're constrained on the number of
> running instances in our providers (ignoring for a moment the
> spin-up/tear-down overhead incurred per job which, if you're
> talking about long-running jobs anyway, is less wasteful than it is
> for lots of very quick jobs). The number of puppet changes and
> number of jobs currently run on each is considerably lower than a
> lot of our other teams as well.
> --
> 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
>
-- 

--

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


Re: [openstack-dev] [puppet] Moving puppet-ceph to the Openstack big tent

2015-09-29 Thread Andrew Woodward
[I'm cross posting this to the other Ceph threads to ensure that it's seen]

We've discussed this on Monday on IRC and again in the puppet-openstack IRC
meeting. The current census is that we will move from the deprecated
stackforge organization and will be moved to the openstack one. At this
time we will not be perusing membership as a formal OpenStack project. This
will allow puppet-ceph to retain the tight relationship with OpenStack
community and tools for the time being.

On Mon, Sep 28, 2015 at 8:32 AM David Moreau Simard <d...@redhat.com> wrote:

> Hi,
>
> puppet-ceph currently lives in stackforge [1] which is being retired
> [2]. puppet-ceph is also mirrored on the Ceph Github organization [3].
> This version of the puppet-ceph module was created from scratch and
> not as a fork of the (then) upstream puppet-ceph by Enovance [4].
> Today, the version by Enovance is no longer officially maintained
> since Red Hat has adopted the new release.
>
> Being an Openstack project under Stackforge or Openstack brings a lot
> of benefits but it's not black and white, there are cons too.
>
> It provides us with the tools, the processes and the frameworks to
> review and test each contribution to ensure we ship a module that is
> stable and is held to the highest standards.
> But it also means that:
> - We forego some level of ownership back to the Openstack foundation,
> it's technical committee and the Puppet Openstack PTL.
> - puppet-ceph contributors will also be required to sign the
> Contributors License Agreement and jump through the Gerrit hoops [5]
> which can make contributing to the project harder.
>
> We have put tremendous efforts into creating a quality module and as
> such it was the first puppet module in the stackforge organization to
> implement not only unit tests but also integration tests with third
> party CI.
> Integration testing for other puppet modules are just now starting to
> take shape by using the Openstack CI inrastructure.
>
> In the context of Openstack, RDO already ships with a mean to install
> Ceph with this very module and Fuel will be adopting it soon as well.
> This means the module will benefit from real world experience and
> improvements by the Openstack community and packagers.
> This will help further reinforce that not only Ceph is the best
> unified storage solution for Openstack but that we have means to
> deploy it in the real world easily.
>
> We all know that Ceph is also deployed outside of this context and
> this is why the core reviewers make sure that contributions remain
> generic and usable outside of this use case.
>
> Today, the core members of the project discussed whether or not we
> should move puppet-ceph to the Openstack big tent and we had a
> consensus approving the move.
> We would also like to hear the thoughts of the community on this topic.
>
> Please let us know what you think.
>
> Thanks,
>
> [1]: https://github.com/stackforge/puppet-ceph
> [2]: https://review.openstack.org/#/c/192016/
> [3]: https://github.com/ceph/puppet-ceph
> [4]: https://github.com/redhat-cip/puppet-ceph
> [5]: https://wiki.openstack.org/wiki/How_To_Contribute
>
> David Moreau Simard
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- 

--

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


[openstack-dev] [fuel] Weekly IRC meeting 9/24

2015-09-23 Thread Andrew Woodward
As a reminder, the weekly IRC meeting is scheduled for 16:00 UTC Tomorrow
in #openstack-meeting-alt

Please review meeting agenda and update if there is something you wish to
discuss.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


[openstack-dev] [Fuel] Meeting 8/6

2015-08-05 Thread Andrew Woodward
Please note the IRC meeting is scheduled for 16:00 UTC Tomorrow in
#openstack-meeting-alt

Please review meeting agenda and update if there is something you wish to
discuss.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

-- 

--

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


[openstack-dev] [fuel] Meeting 7/30

2015-07-30 Thread Andrew Woodward
Please note the IRC meeting is scheduled for 16:00 UTC (about 1 hour from
now) in #openstack-meeting-alt

Please review meeting agenda and update if there is something you wish to
discuss.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda

-- 

--

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


Re: [openstack-dev] [puppet] Parameters possible default value

2015-07-30 Thread Andrew Woodward
On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia sba...@redhat.com wrote:

 On Mon, Jul 27, 2015 at 09:43:28PM (+), Andrew Woodward wrote:
  Sorry, I forgot to finish this up and send it out.
 
  #--SNIP--
  def absent_default(
$value,
$default,
$unset_when_default = true,
  ){
if ( $value == $default ) and $unset_when_default {
  # I cant think of a way to deal with this in a define so lets pretend
  # we can re-use this with multiple providers like we could if this
 was
  # in the actual provider.
 
  keystone_config {$name: ensure = absent,}
} else {
  keystone_config {$name: value = $value,}
}
  }
 
  # Usage:
  absent_default{'DEFAULT/foo': default = 'bar', value = $foo }

 Hi,

 Hum, but you want to add this definition in all our modules, or directly in
 openstacklib?


I only mocked it up in a puppet define, because its easier for me (my ruby
is terrible) It should be done by adding these kinds of extra providers to
the inifile provider override that Yanis proposed.



 In case of openstacklib, in which manner do you define the
 component_config
 resource? (eg, generic def, but specialized resource).

  #--SNIP--
 
  (I threw this together and haven't tried to run it yet, so It might not
 run
  verbatim, I will create a test project with it to show it working)
 
  So In the long-term we should be able to add some new functionality to
 the
  inifile provider to simply just do this for us. We can add the 'default'
  and 'unset_when_default' parameter so that we can use them straight w/o a
  wrapping function (but the warping function could be used too). This
 would
  give us the defaults (I have an idea on that too that I will try to put
  into the prototype) that should allow us to have something that looks
 quite
  clean, but is highly functional
 
   Keystone_config{unset_when_default = true} #probably flatly enabled in
  our inifile provider for the module
   keystone_config {'DEFAULT/foo': value = 'bar', default = 'bar'}


 I'm not sure to see the difference with the Yanis solution here¹, and not
 sure
 to see the link between the define resource and the type/provider resource.


This adds on to Yanis' solution so that we can authoritatively understand
what the default value is, and how it should be treated (instead of hoping
some magic word doesn't conflict)

Seb

 ¹https://review.openstack.org/#/c/202574/
 --
 Sebastien Badia
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

--

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


Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

2015-07-28 Thread Andrew Woodward
IIRC the puppet modules, and even the heat domain create script make use of
the token straight from the config file. It not being present could cause
problems for some of the manifests. We would need to ensure that their
usage is minimized or removed.

On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk sgolovat...@mirantis.com
wrote:

 Hi Oleksiy,

 Good catch. Also OSTF should get endpoints from hiera as some plugins may
 override the initial deployment settings. There may be cases when keystone
 is detached by plugin.

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

 On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov 
 omolcha...@mirantis.com wrote:

 Hello all,

 We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
 deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619.
 I guess not all of us have an access to this bug, so to be short:

 # A shared secret that can be used to bootstrap Keystone.
 # This token does not represent a user, and carries no
 # explicit authorization. To disable in production (highly
 # recommended), remove AdminTokenAuthMiddleware from your
 # paste application pipelines (for example, in keystone-
 # paste.ini). (string value)

 After removing this and testing we found out that OSTF fails because it
 uses admin token.

 What do you think if we create ostf user like for workloads, but with
 wider permissions?

 BR,
 Oleksiy.

 __
 OpenStack Development Mailing 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

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


Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

2015-07-28 Thread Andrew Woodward
It's literally how radosgw goes about verifying users, it has no scheme of
using a user or working with auth-tokens. It would have to fixed in the
ceph-radosgw codebase. PKI tokens (which we don't use) rely on this less,
but its still used.

On Tue, Jul 28, 2015 at 2:16 PM Sergii Golovatiuk sgolovat...@mirantis.com
wrote:

 Why can't radosgw use own own credentials? If it's technical debt we need
 to put it on plate to address in next release.


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

 On Tue, Jul 28, 2015 at 10:21 PM, Andrew Woodward xar...@gmail.com
 wrote:

 Keystone authtoken is also used by radosgw to validate users

 On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward awoodw...@mirantis.com
 wrote:

 IIRC the puppet modules, and even the heat domain create script make use
 of the token straight from the config file. It not being present could
 cause problems for some of the manifests. We would need to ensure that
 their usage is minimized or removed.

 On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk 
 sgolovat...@mirantis.com wrote:

 Hi Oleksiy,

 Good catch. Also OSTF should get endpoints from hiera as some plugins
 may override the initial deployment settings. There may be cases when
 keystone is detached by plugin.

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

 On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov 
 omolcha...@mirantis.com wrote:

 Hello all,

 We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
 deployment. This came from
 https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us
 have an access to this bug, so to be short:

 # A shared secret that can be used to bootstrap Keystone.
 # This token does not represent a user, and carries no
 # explicit authorization. To disable in production (highly
 # recommended), remove AdminTokenAuthMiddleware from your
 # paste application pipelines (for example, in keystone-
 # paste.ini). (string value)

 After removing this and testing we found out that OSTF fails because
 it uses admin token.

 What do you think if we create ostf user like for workloads, but with
 wider permissions?

 BR,
 Oleksiy.


 __
 OpenStack Development Mailing 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

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

 --

 --

 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


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

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


Re: [openstack-dev] [fuel] OS_SERVICE_TOKEN usage in Fuel

2015-07-28 Thread Andrew Woodward
Keystone authtoken is also used by radosgw to validate users

On Tue, Jul 28, 2015 at 10:31 AM Andrew Woodward awoodw...@mirantis.com
wrote:

 IIRC the puppet modules, and even the heat domain create script make use
 of the token straight from the config file. It not being present could
 cause problems for some of the manifests. We would need to ensure that
 their usage is minimized or removed.

 On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk 
 sgolovat...@mirantis.com wrote:

 Hi Oleksiy,

 Good catch. Also OSTF should get endpoints from hiera as some plugins may
 override the initial deployment settings. There may be cases when keystone
 is detached by plugin.

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

 On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov 
 omolcha...@mirantis.com wrote:

 Hello all,

 We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after
 deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619.
 I guess not all of us have an access to this bug, so to be short:

 # A shared secret that can be used to bootstrap Keystone.
 # This token does not represent a user, and carries no
 # explicit authorization. To disable in production (highly
 # recommended), remove AdminTokenAuthMiddleware from your
 # paste application pipelines (for example, in keystone-
 # paste.ini). (string value)

 After removing this and testing we found out that OSTF fails because it
 uses admin token.

 What do you think if we create ostf user like for workloads, but with
 wider permissions?

 BR,
 Oleksiy.


 __
 OpenStack Development Mailing 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

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

-- 

--

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


Re: [openstack-dev] [fuel] Fuel plugin as docker containers images

2015-07-28 Thread Andrew Woodward
I'm still confused are you wanting to add a container to the master node,
or a deployed env?

For the master node, the latest fuel-plugin-builder allows for post-install
scripts, you could load a container image from here
For nodes in a deployed ENV, there is no formal target to support
containers, you would need to install the container manager and containers
yourself.

However I would note that not packaging the applications dependencies
because it's in a container is not a good practice as it quickly becomes
very difficult to work with versioning and updates. It may be acceptable
for a dev build of the plugin, but should be avoided in validated versions
of the plugin. The container its self should also be contained within a
package so that it's versioning can be tracked with operator familiar
tools. Lastly, containers with python are quite large, so if you can get
the versioning to work I'd avoid putting it into a container all together
as you will end up with 150-300mb container mostly just because of python.

On Tue, Jul 28, 2015 at 7:26 AM Konstantin Danilov kdani...@mirantis.com
wrote:

 Evgene,

 I'm sure you understand this, but just to be clear - now FUEL uses
 containers on master node,
 not on cluster nodes. I'm asking about plugin containers on cluster nodes.

 Yep, there a particular example - VSM (Intel ceph management tool). It
 requires a set of packages,
 like python2.6, old django, etc, which I would rather not install on
 master node directly.

 Thanks

 On Tue, Jul 28, 2015 at 10:47 AM, Evgeniy L e...@mirantis.com wrote:
  Hi Konstantin,
 
  I'm not sure if we track such feature anywhere. But one of the reasons
  to use containers on the master was to deliver plugin specific
 containers,
  so they don't intersect and don't break Fuel master dependencies.
  Do you have some specific use case for that?
 
  Thanks,
 
  On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov 
 kdani...@mirantis.com
  wrote:
 
  Hi,
 
  Is there a plans to allow plugin to be delivered as docker container
  images?
 
  Thanks
 
  --
  Kostiantyn Danilov aka koder.ua
  Principal software engineer, Mirantis
 
  skype:koder.ua
  http://koder-ua.blogspot.com/
  http://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
 



 --
 Kostiantyn Danilov aka koder.ua
 Principal software engineer, Mirantis

 skype:koder.ua
 http://koder-ua.blogspot.com/
 http://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

-- 

--

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


Re: [openstack-dev] [puppet] Parameters possible default value

2015-07-27 Thread Andrew Woodward
Sorry, I forgot to finish this up and send it out.

#--SNIP--
def absent_default(
  $value,
  $default,
  $unset_when_default = true,
){
  if ( $value == $default ) and $unset_when_default {
# I cant think of a way to deal with this in a define so lets pretend
# we can re-use this with multiple providers like we could if this was
# in the actual provider.

keystone_config {$name: ensure = absent,}
  } else {
keystone_config {$name: value = $value,}
  }
}

# Usage:
absent_default{'DEFAULT/foo': default = 'bar', value = $foo }

#--SNIP--

(I threw this together and haven't tried to run it yet, so It might not run
verbatim, I will create a test project with it to show it working)

So In the long-term we should be able to add some new functionality to the
inifile provider to simply just do this for us. We can add the 'default'
and 'unset_when_default' parameter so that we can use them straight w/o a
wrapping function (but the warping function could be used too). This would
give us the defaults (I have an idea on that too that I will try to put
into the prototype) that should allow us to have something that looks quite
clean, but is highly functional

 Keystone_config{unset_when_default = true} #probably flatly enabled in
our inifile provider for the module
 keystone_config {'DEFAULT/foo': value = 'bar', default = 'bar'}




On Mon, Jul 27, 2015 at 3:06 AM Yanis Guenane yguen...@redhat.com wrote:



 On 07/20/2015 10:07 AM, Martin Mágr wrote:
  Hey Yanis
 
  On 07/17/2015 10:56 AM, Yanis Guenane wrote:
  Hello everyone,
 
 
  if set the value would have been set else it would default to upstream
  default.
 
  But Mathieu raised a fair point here[2] is that an empty string for some
  settings is a valid value, and hence we can't rely on
  it.
 
  Since the beginning we are trying to avoid the use of a magic string,
  but
  I am starting to run out of idea here.
 
  Does someone has an idea on which sane value the default could be ?
 
  How about  '*config_default*'? Or whatever similar which says you want
  the default value, but will potentially never be value of any parameter.
 
  Regards,
  Martin
 
 
  Thanks in advance,
 
  [1] https://review.openstack.org/#/c/202488
  [2] https://review.openstack.org/#/c/202574
  --
  Yanis Guenane
 
 
 __
 
  OpenStack Development Mailing 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

 Following on the thread, and following the discussion that took place
 during last week meeting[1],

 The patchset[2] and the example[3] have been updated not to ensure
 absent for a nil string due to its valid usage in some cases,
 but to ensure absent when 'SERVICE DEFAULT' is specified. Based on the
 community feedback this string
 isn't used across any component.

 During the meeting xarses had an alternative idea, if once mocked up you
 could send a follow-up mail in this
 thread so we can grasp the idea.

 @Mathieu: if the new approach is ok with you, could you please review
 your -2 on that patchset

 Thanks in advance for your feedbacks,

 [1]

 http://eavesdrop.openstack.org/meetings/puppet/2015/puppet.2015-07-21-14.59.log.html
 [2] https://review.openstack.org/#/c/202574/
 [3] https://review.openstack.org/#/c/202513/

 --
 Yanis Guenane


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

-- 

--

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


Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

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


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




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




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



 __
 OpenStack Development Mailing 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

-- 

--

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


Re: [openstack-dev] [Fuel] FFE requests and status

2015-07-24 Thread Andrew Woodward
Current FFE request status:

FFE for bug/1475759 ceph generators - PENDING Approval
FF Exception request for Fernet tokens support. - DECLINED
FF Exception request for Custom node attributes feature - APPROVED, MERGED
FF Exception request for Templates for Networking feature - APPROVED
FF Exception for LP-1464656 fix (update ceph PG calculation algorithm) -
PENDING Approval
FF Exception request for Env Upgrade feature - APPROVED
FF Exception request for Deploy nova-compute (VCDriver) feature - PENDING
Approval


On Thu, Jul 23, 2015 at 12:17 PM Mike Scherbakov mscherba...@mirantis.com
wrote:

 Thanks Andrew.

 I'd like to add that after there is an announcement about FF, all core
 reviewers should stop getting patches into master which are parts of
 features or extensions. We expect only bugfixes. If there is anything else,
 we need to be very transparent about it, and have them in public place like
 here.

 In the past, we had a practice when developers would continue to work on
 enhancements instead of bugs, and cores would support it. And in fact, FF
 moves to SCF - and we have to slip our release. Let's not do this again.


 On Thu, Jul 23, 2015 at 11:56 AM Andrew Woodward xar...@gmail.com wrote:

 In case you missed it, feature freeze is today and in the rush to merge
 things, you may have had issues with getting everything landed.

 For those that are not familiar with the process, to request a feature
 freeze exception (FFE):

 * You will need to raise the request to the ML here and in such message
 - Include [Fuel] FFE request + feature name in the subject
 - Document what is outstanding (Link to CR's), what's their state
 - Link to blueprint
 - Document impact of outstanding changes
 - Document how long you expect before it can lang
 * You will also need to get two of the cores in the repo(s) impacted by
 outstanding reviews to sponsor reviewing the outstanding CR's
 * Finally PTL will approve each FFE request.

 Please do not ask for a FFE in this thread

 I will update this thread with approved FFE's as they occur

 --

 --

 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

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

-- 

--

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


[openstack-dev] [fuel] Acting PTL for Fuel - Dmitry Borodaenko

2015-07-24 Thread Andrew Woodward
I'd like to point out as part of our on-going effort to more formally align
with the openstack governance practices, Dmitry Borodaenko has taken up the
reins as PTL for fuel as this aligns with his current leadership role in
the project.

We have agreed that we will open for nominations and voting After HCF
(towards the end of the 7.0 release cycle in September)
-- 

--

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


Re: [openstack-dev] [fuel] FF Exception for LP-1464656 fix (update ceph PG calculation algorithm)

2015-07-24 Thread Andrew Woodward
+1 for FFE
Given how borken pg_num calculations are now, this is essential to the ceph
story and there is no point in testing ceph at scale with out it.

The only work-around for not having this is to delete all of the pools by
hand after deployment and calculate the values by hand, and re-create the
pools by hand. The story from that alone makes it high on the UX scale,
which means we might as well fix it as a bug.

The scope of impact is limited to only ceph, the testing plan needs more
detail, and we are still comming to turns with some of the data format to
process between nailgun calculating and puppet consuming.

We would need about 1.2 week to get these landed.

On Fri, Jul 24, 2015 at 3:51 AM Konstantin Danilov kdani...@mirantis.com
wrote:

 Team,

 I would like to request an exception from the Feature Freeze for [1]
 fix. It requires changes in
 fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already
 tested, I'm fixing UT now.
 BP - [4]

 Code has backward-compatibility mode. I need one more week to finish it.
 Also
 I'm asking someone to be an assigned code-reviewer for this ticket to
 speed-up
 review process.

 Thanks

 [1] https://bugs.launchpad.net/fuel/+bug/1464656
 [2] https://review.openstack.org/#/c/204814
 [3] https://review.openstack.org/#/c/204811
 [4] https://review.openstack.org/#/c/203062

 --
 Kostiantyn Danilov aka koder.ua
 Principal software engineer, Mirantis

 skype:koder.ua
 http://koder-ua.blogspot.com/
 http://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

-- 

--

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


[openstack-dev] [fuel] FFE for bug/1475759 ceph generators

2015-07-24 Thread Andrew Woodward
I'm writing to ask for a FFE for landing the ceph generators. It finally
received core-reviewers attention late on Wednesday and Thursday and is
ready to merge now. I'm only asking for FFE because reviewers are calling
this a feature.

Possible impact, none. This is not used by anything yet and should be
merged.

[1] https://bugs.launchpad.net/fuel/+bug/1475759
[2] https://review.openstack.org/#/c/203270/
-- 

--

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


Re: [openstack-dev] [Fuel] version.yaml in the context of packages

2015-07-24 Thread Andrew Woodward
Vladimir,

I agree that the content of this file nearly completely depreciated, but
slightly disagree with removing it entirely.

I think the data should be moved from a single static file like you see
here, to something that reads the data from the underlying packages and can
still show all of the information in one place (/api/version). So we can,
and should do away with this file but we need the data in the api response,
and saved in the diag snapshot. So my comments below are about possibly
keeping these around, but not in the file

On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Dear colleagues,

 Although we are focused on fixing bugs during next few weeks I still have
 to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this
 file when all-inclusive ISO image was the only way of delivering Fuel. We
 had to have somewhere the information about SHA commits for all Fuel
 related git repos. But everything is changing and we are close to flexible
 package based delivery approach. And this file is becoming kinda fifth
 wheel.

 Here is how version.yaml looks like

 VERSION:
   feature_groups:
 - mirantis
   production: docker
   release: 7.0
   openstack_version: 2015.1.0-7.0
   api: 1.0
   build_number: 82
   build_id: 2015-07-23_10-59-34
   nailgun_sha: d1087923e45b0e6d946ce48cb05a71733e1ac113
   python-fuelclient_sha: 471948c26a8c45c091c5593e54e6727405136eca
   fuel-agent_sha: bc25d3b728e823e6154bac0442f6b88747ac48e1
   astute_sha: b1f37a988e097175cbbd14338286017b46b584c3
   fuel-library_sha: 58d94955479aee4b09c2b658d90f57083e668ce4
   fuel-ostf_sha: 94a483c8aba639be3b96616c1396ef290dcc00cd
   fuelmain_sha: 68871248453b432ecca0cca5a43ef0aad6079c39


 Let's go through this file.

 1) *feature_groups* - This is, in fact, runtime parameter rather then
 build one, so we'd better store it in astute.yaml or other runtime config
 file.

This should just be expressed as a value in the DB, it never made sense to
store this in a file since it's runtime state

 2) *production* - It is always equal to docker which means we deploy
 docker containers on the master node. Formally it comes from one of
 fuel-main variables, which is set into docker by default, but not a
 single job in CI customizes this variable. Looks like it makes no sense to
 have this.

there is no longer not docker, so just drop it.

 3) *release *- It is the number of Fuel release. Frankly, don't need this
 because it is nothing more than the version of fuel meta package [1].
 4) *openstack_version *- It is just an extraction from openstack.yaml [2].
 5) *api *- It is 1.0 currently. And we still don't have other versions of
 API. Frankly, it contradicts to the common practice to make several
 different versions available at the same time. And a user should be able to
 ask API which versions are currently available.
 6) *build_number *and *build_id *- These are the only parameters that
 relate to the build process. But let's think if we actually need these
 parameters if we switch to package based approach. RPM/DEB repositories are
 going to become the main way of delivering Fuel, not ISO. So, it also makes
 little sense to put store them, especially if we upgrade some of the
 packages.

These are useful to track which iso the issue occurred in and if my iso or
another might have the issue. I find it the attributes I use the most in
this data. Again is un-related to packages so it should only be copied off
the iso for development reasons

 7) *X_sha* - This does not even require any explanation. It should be rpm
 -qa instead.

We need this information. It can easily be replaced with the identifier
from the package, but it still needs to describe source. We need to know
exactly which commit was the head. It's solved many other hard to find
problems that we added it for in the first place


 I am raising this topic, because it is kind of blocker for switching to
 package based upgrades. Our current upgrade script assumes we have this
 file version.yaml in the tarball and we put this new file instead of old
 one during upgrade. But this file could not be packaged into rpm because it
 can only be built together with ISO.


 [1]
 https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec
 [2]
 https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml

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

-- 

--

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

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

2015-07-24 Thread Andrew Woodward
On Fri, Jul 24, 2015 at 2:12 AM Evgeniy L e...@mirantis.com wrote:

 Hi Andrew,

 I don't agree with you, user should be able to name the node any way he
 wants why there should be a constraint which is related to some internal id
 in Nailgun database? For example if he deleted node-5 and then he wants
 to replace this node with another one, he can and should be able to provide
 for this replacement node hostname node-5, even if node's id in the
 database
 is 6.


No, its easier to just change the node id in the database to 5 if that is
what they want. We own the namespace 'node-node.id' schema. If they want
to use that schema then they have to update node.id in the database. We
have multiple areas in the code where we do special things based on the ID
of the node (like primary member of role). If they wanted to replace the
node and get the old host-name back then there is a very high chance that
the expect it to continue to have these special functions applied to them

I don't know why we want to create a custom conflict resolution scheme here
when we can reasonably say its not allowed.

There are things we have to check now which increases the complication when
we allow this.

A) As a pre-requisite to setting any hostname, we must now generate all of
the hostnames so that we can check if there is a node-node.id conflict.
B) After (A) and we find that there are no conflicts we can now set the
host name
C) New node is added to the cluster with id that now conflicts with the
node.id format for this name (higher or lower is possible) how do we want
to generate new nodes hostname. We dont want to fail the deployment because
of it so we have to resort to some weird naming scheme like discussed here.
But what happens if user doesn't want that ugly name if we do this
automatically then they could end up with some ugly name that they then
have to erase the node before they can change.

Seems like a waste of time to me. We can avoid this all by simply asking
the user to change the node.id in the database so that this complicated
stuff can be avoided



Thanks,

 On Fri, Jul 24, 2015 at 2:36 AM, Andrew Woodward xar...@gmail.com wrote:



 On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com
 wrote:

 Thanks for your answers.

 Let me clarify some points:

 Sure, we have to validate hostnames during node renaming. And sure we do
 it. This issue appears when we already have node with name 'node-X' and new
 node is created without providing custom name. I'll give you the example:

 1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
 with ID  4) ;
 2. He renames it in 'node-5' (this name is correct and unique. OK)
 3. He adds new node without providing custom hostname.
 New node gets ID = 5 (it's primary key and increments automatically)
 and default hostname 'node-5'. (Here we have a problem with uniqueness.)

 It will be strange if we refuse to create node with default name if
 somebody has renamed another node using this name.

 About nodes hostnames. Actually we can't refuse to use custom hostnames
 in format 'node-{#}' because it is one of the main use cases. So we need to
 find the solution which accepts such renaming.

 How is this a main use case? This is exactly what we should not support.
 If they want the node to have 'node-5' as it's hostname we need them to be
 node.id = 5 (IE the node id in the DB is 5) They would not need custom
 node naming in this case.


 2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Hi guys,

 @Sergii, it looks like you misunderstood something. `node-uuid` is not
 a general use case. It's only about conflicting nodes, and I'm sure
 everyone's going to change such a hostname in order to avoid
 confusion.

 @Andrew,

 a) Database refuses hostnames that break unique constraint, sot it'll
 work out-of-box.

 b) I like this idea. I think refusing `node-id` where `id` is not
 actually a node id is good idea. It solves our problem.

 Thanks,
 Igor

 On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
 sgolovat...@mirantis.com wrote:
  node-uuid is very terrible from UX perspective of view. Ask support
 people
  if they are comfortable to ssh such nodes or telling the name in phone
  conversation with customer. If we cannot validate FQDN of hostname I
 would
  slip this feature to next release where we can pay more attention to
  details.
 
  --
  Best regards,
  Sergii Golovatiuk,
  Skype #golserge
  IRC #holser
 
 
 __
  OpenStack Development Mailing 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

Re: [openstack-dev] [Fuel] Question about unique default hostname for node

2015-07-23 Thread Andrew Woodward
On Wed, Jul 22, 2015 at 6:32 AM Fedor Zhadaev fzhad...@mirantis.com wrote:

 Thanks for your answers.

 Let me clarify some points:

 Sure, we have to validate hostnames during node renaming. And sure we do
 it. This issue appears when we already have node with name 'node-X' and new
 node is created without providing custom name. I'll give you the example:

 1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
 with ID  4) ;
 2. He renames it in 'node-5' (this name is correct and unique. OK)
 3. He adds new node without providing custom hostname.
 New node gets ID = 5 (it's primary key and increments automatically)
 and default hostname 'node-5'. (Here we have a problem with uniqueness.)

 It will be strange if we refuse to create node with default name if
 somebody has renamed another node using this name.

 About nodes hostnames. Actually we can't refuse to use custom hostnames in
 format 'node-{#}' because it is one of the main use cases. So we need to
 find the solution which accepts such renaming.

How is this a main use case? This is exactly what we should not support. If
they want the node to have 'node-5' as it's hostname we need them to be
node.id = 5 (IE the node id in the DB is 5) They would not need custom node
naming in this case.


 2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Hi guys,

 @Sergii, it looks like you misunderstood something. `node-uuid` is not
 a general use case. It's only about conflicting nodes, and I'm sure
 everyone's going to change such a hostname in order to avoid
 confusion.

 @Andrew,

 a) Database refuses hostnames that break unique constraint, sot it'll
 work out-of-box.

 b) I like this idea. I think refusing `node-id` where `id` is not
 actually a node id is good idea. It solves our problem.

 Thanks,
 Igor

 On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
 sgolovat...@mirantis.com wrote:
  node-uuid is very terrible from UX perspective of view. Ask support
 people
  if they are comfortable to ssh such nodes or telling the name in phone
  conversation with customer. If we cannot validate FQDN of hostname I
 would
  slip this feature to next release where we can pay more attention to
  details.
 
  --
  Best regards,
  Sergii Golovatiuk,
  Skype #golserge
  IRC #holser
 
 
 __
  OpenStack Development Mailing 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




 --
 Kind Regards,
 Fedor Zhadaev
 Junior Software Engineer, Mirantis Inc.
 Skype: zhadaevfm
 E-mail: fzhad...@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

-- 

--

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


Re: [openstack-dev] [fuel][puppet] Module Sync for Murano and Sahara

2015-07-23 Thread Andrew Woodward
Denis,

Now that I have better understanding of the history of the commit, I
understand that this was the best way through. The Sahara and Murano team's
effort was invaluable in getting these fixed up and in a good state. I
apologize that I have raised this as an issue. I was very concerned with
the commits before knowing theses details, It was necessary to get the
clarification.

Let me clarify what I understand now was going on with them.

Sahara.
A )Fuel had a number of better parts of the fork. there where two commits
[1][2] proposed to puppet-sahara from Fuel that where not merged that
reflected the better side of Fuel's fork.
B) The Sahara sync commit [3] into fuel represented upstream puppet-sahara
C) The Adapt commit [4] contained the two commits listed prior in A, kilo
support, stuff we needed to ensure it worked in fuel and Noop tests.

[1] https://review.openstack.org/#/c/198744/
[2] https://review.openstack.org/#/c/192721/
[3] https://review.openstack.org/#/c/202045
[4] https://review.openstack.org/#/c/202195/

Murano
D) Fuel has effectively the only usable Murano module
E) The Adapt commit [5] represented
* a major over hall of the code quality to make it suitable to propose
upstream
* fixes necessary to support kilo
* cleanup for modular
* Noop tests

[5] https://review.openstack.org/#/c/203731/

With the improved clarity of what was going on, it made it much easier
understand what I was reviewing and I'm glad of the current state.

Here are my thoughts on what we can do better next time:
* The commit and CR messages where not sufficient to understand entirely
what was going on with the commits and how it was tested.
* Separate out some of the changes into a commit chain to reduce the scope
of each CR so that its easier to review.
* For large reviews like this, we should let more reviewers know whats
going on the ML early. These showed up on my radar late and of course, I
freaked out.



On Wed, Jul 22, 2015 at 6:51 AM Denis Egorenko degore...@mirantis.com
wrote:

 Hi Andrew!

 Sahara already merged. All CI tests were succeeded, also was built custom
 iso [1] and ran bvt tests [2], which also were succeeded and we got +1 from
 QA team.
 For Murano we will do the same: resolve all comments, build custom iso,
 run custom bvt and wait +1 from Fuel CI and QA team.

 [1]
 http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_7.0_iso/562/

 [2]
 http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/7.0.custom.ubuntu.bvt_2/131/

 2015-07-22 0:41 GMT+03:00 Andrew Woodward xar...@gmail.com:

 I was looped into reviewing the sync commits for Murano and Sahara. Both
 are in terrible shape and risk feature freeze at this point.

 We need feed back from the authors here. What is actually required for
 Kilo support (if any)from the Murano and Sahara modules? What will happen
 if these slip the release. What can you do to simplify the review scope.
 The most we can reasonably review is 500 LOC in any short time (and that's
 pushing it).

 Synopsis:
 murano [1] is -2, this can't be merged; there is a adapt commit with out
 any sync commit. The only way we will accept the fork method is a sync from
 upstream +adapt as documented in [2] also it's neigh impossible to review
 something this large with out the separation.
 -2 There is no upstream repo with content, so where did this even come
 from? We are/where the authority for murano at present so I'm baffled as to
 where this came from.

 Possible way through: A) Split sync from adapt, hopefully the adapt is
 small enough to to review. B)Make only changes necessary for kilo support.

 Sahara [3][4]
 This is a RED flah here, I'm not even sure to call it -1, -2 or something
 entirely else. I had with Serg M, This is a sync of upstream, plus the code
 on review from fuel that is not merged into puppet-sahara. I'm going to say
 that our fork is in much better shape at this moment, and we should just
 let it be. We shouldn't sync this until the upstream code is landed.

 Possible way through: C) The two outstanding commits inside the adapt
 commit need to be pulled out. They should be proposed right on top of the
 sync commit and should apply cleanly. I would prefer to see them as
 separate commits so they can be compared to the source more accurately.
 This should bring the adapt to something that could be reviewed. D) propose
 only the changes necessary to get kilo support.

 [1] https://review.openstack.org/#/c/203731/
 [2]
 https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Adding_new_puppet_modules_to_fuel-library
 [3] https://review.openstack.org/#/c/202045
 [4] https://review.openstack.org/#/c/202195/
 --

 --

 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

[openstack-dev] [Fuel] FFE requests and status

2015-07-23 Thread Andrew Woodward
In case you missed it, feature freeze is today and in the rush to merge
things, you may have had issues with getting everything landed.

For those that are not familiar with the process, to request a feature
freeze exception (FFE):

* You will need to raise the request to the ML here and in such message
- Include [Fuel] FFE request + feature name in the subject
- Document what is outstanding (Link to CR's), what's their state
- Link to blueprint
- Document impact of outstanding changes
- Document how long you expect before it can lang
* You will also need to get two of the cores in the repo(s) impacted by
outstanding reviews to sponsor reviewing the outstanding CR's
* Finally PTL will approve each FFE request.

Please do not ask for a FFE in this thread

I will update this thread with approved FFE's as they occur

-- 

--

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


Re: [openstack-dev] [fuel] Meeting 7/23

2015-07-23 Thread Andrew Woodward
Yep, forgot to include the topics i referred to

Topics not covered in todays meeting, but requested in the agenda

* ubuntu based bootstrap has been merged, needs thorough testing
(kozhukalov)
* Let's switch keystone under Apache right after FF (adidenko)
* Separate services from controller status (mattymo)
* (?) update iso build process(rpm\deb\repositories\nailgun pinning\IBP)
(azvyagintsev)  (didn't appear in a meeting)
* (?) status of upgrade module = package (azvyagintsev) (didn't appear in
a meeting)
* Enable deployment through Packer and Vagrant, and/or publish vagrant
boxes and Vagrantfiles for standard deployments locally (crimi) (didn't
appear in a meeting)


On Thu, Jul 23, 2015 at 11:10 AM Andrew Woodward xar...@gmail.com wrote:

 Today's meeting was a little hectic, if you have a topic on the agenda,
 ensure you are present and ready to speak, or move your topic lower in the
 agenda. When possible, pre-type you main points of discussion and copy and
 paste it into the channel when your topic comes up. This tends to save a
 bit of time and allows us to move through the topics more quickly.

 The minutes [2] are available and the following topics where missed.
 Please raise them in the ML if they should be discussed prior to the next
 meeting.

 [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
 [2]
 http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-23-16.00.html
 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community

-- 

--

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


[openstack-dev] [fuel] Meeting 7/23

2015-07-23 Thread Andrew Woodward
Today's meeting was a little hectic, if you have a topic on the agenda,
ensure you are present and ready to speak, or move your topic lower in the
agenda. When possible, pre-type you main points of discussion and copy and
paste it into the channel when your topic comes up. This tends to save a
bit of time and allows us to move through the topics more quickly.

The minutes [2] are available and the following topics where missed. Please
raise them in the ML if they should be discussed prior to the next meeting.

[1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
[2]
http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-23-16.00.html
-- 

--

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


[openstack-dev] [fuel][puppet] Module Sync for Murano and Sahara

2015-07-21 Thread Andrew Woodward
I was looped into reviewing the sync commits for Murano and Sahara. Both
are in terrible shape and risk feature freeze at this point.

We need feed back from the authors here. What is actually required for Kilo
support (if any)from the Murano and Sahara modules? What will happen if
these slip the release. What can you do to simplify the review scope. The
most we can reasonably review is 500 LOC in any short time (and that's
pushing it).

Synopsis:
murano [1] is -2, this can't be merged; there is a adapt commit with out
any sync commit. The only way we will accept the fork method is a sync from
upstream +adapt as documented in [2] also it's neigh impossible to review
something this large with out the separation.
-2 There is no upstream repo with content, so where did this even come
from? We are/where the authority for murano at present so I'm baffled as to
where this came from.

Possible way through: A) Split sync from adapt, hopefully the adapt is
small enough to to review. B)Make only changes necessary for kilo support.

Sahara [3][4]
This is a RED flah here, I'm not even sure to call it -1, -2 or something
entirely else. I had with Serg M, This is a sync of upstream, plus the code
on review from fuel that is not merged into puppet-sahara. I'm going to say
that our fork is in much better shape at this moment, and we should just
let it be. We shouldn't sync this until the upstream code is landed.

Possible way through: C) The two outstanding commits inside the adapt
commit need to be pulled out. They should be proposed right on top of the
sync commit and should apply cleanly. I would prefer to see them as
separate commits so they can be compared to the source more accurately.
This should bring the adapt to something that could be reviewed. D) propose
only the changes necessary to get kilo support.

[1] https://review.openstack.org/#/c/203731/
[2]
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Adding_new_puppet_modules_to_fuel-library
[3] https://review.openstack.org/#/c/202045
[4] https://review.openstack.org/#/c/202195/
-- 

--

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


Re: [openstack-dev] [Fuel] Question about unique default hostname for node

2015-07-21 Thread Andrew Woodward
On Tue, Jul 21, 2015 at 5:38 AM Fedor Zhadaev fzhad...@mirantis.com wrote:

 Hi all,

 The next issue was found during implementation
 https://blueprints.launchpad.net/fuel/+spec/node-naming :

   User may change node hostname to any another, including default-like
 'node-{№}', where № may be bigger than maximum nodeID existing at that
 moment.
   Later when node with ID == № will be created it's default name
 'node-{ID}' will break hostnames uniqueness.

 To avoid this now it was decided to generate in such situation another
 default hostname.

 The current solution is to generate hostname '*node-{UUID}*'. It works,
 but may look terribly.

 There are a few another possible solutions:

- Use '*node-{ID}-{#}*' format, where *{#} *we'll chose in loop till
the first unique.
- Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)

 I think the only solution here is to a) ensure that every hostname is
unique or refuse to update the value b)In cases that the user wants to use
our format, the only allowed format is node-{ID} where ID must be equal to
this nodes ID. we don't need to come up with some scheme to rescue the
format. We do however need some value/method that will make it reset back
to the default.


 Please share you opinion - what is better?

 Also you can propose your own solutions.

 --
 Kind Regards,
 Fedor Zhadaev
 Junior Software Engineer, Mirantis Inc.
 Skype: zhadaevfm
 E-mail: fzhad...@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

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


Re: [openstack-dev] [fuel] NodeGroups vs network-templates and static routes

2015-07-20 Thread Andrew Woodward
Ya, that makes sense now that you mention it. We will still need node
groups to act as partitioning for the rack values

On Mon, Jul 20, 2015 at 1:44 AM Sergey Vasilenko svasile...@mirantis.com
wrote:


 On Thu, Jul 16, 2015 at 10:53 PM, Andrew Woodward xar...@gmail.com
 wrote:

 Regardless of computing all the routes, we need to compute same role, but
 multi-segement routes. In this case I see that nodegroups becomes
 redundant. It's only value is that it may be a simpler interface then
 templates but it imposes the old network topology which I could see people
 wanting to get away from.


 I do not agree with unnecessary node groups.
 Yes, move route calculation is a good idea and I think we should implement
 it.

 But removing node groups... When we will implement multi-rack feature we
 will need some abstraction for store rack-specific attributes. Node groups
 are seems appropriate for this role.

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

-- 

--

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


[openstack-dev] [fuel][CI] Fuel-web CI is broken

2015-07-20 Thread Andrew Woodward
I found this after noon that fuel-web CI was broken due to the recent
release of oslo.config and oslo.utils 2.0.0 [1]

I attempted to muck around with the pinning of the requirements.txt and had
initial success with it [2] but later found that it's failing the
test_check_requirements_conflicts task. I'm at a loss on how to properly
fix the requirements for pbr here.

I've also started another commit to get fuel web off of the old namespace
[4]

[1] https://bugs.launchpad.net/fuel/+bug/1476399
[2] https://review.openstack.org/#/c/203824
[3]
https://ci.fuel-infra.org/job/verify-fuel-web/2626/testReport/nailgun.test.unit/test_requirements/test_check_requirements_conflicts/
[4] https://review.openstack.org/#/c/203847/
-- 
--
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


Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

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


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




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




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



 __
 OpenStack Development Mailing 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

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


Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

2015-07-17 Thread Andrew Woodward
Fantastic, do we have some way to validate that the module was pulled in
properly as part of fuel-library CI?

On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com wrote:

 Hey All,

 I've figured it out without having to modify the fuel-main build code.
 I've updated the fuel-library spec with a build action that invokes the
 script to pull down external modules.  Please take some time to review the
 two reviews out there for this change to see if there are any issues with
 the way it is implemented.

 https://review.openstack.org/#/c/202763/
 https://review.openstack.org/#/c/202767/

 This is a first step towards being able to pull in unmodified external
 puppet modules.

 Thanks,
 -Alex

 On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com
 wrote:



 On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main patch to
 invoke this script right before building fuel-library package. I'll add you
 to review it. Is it ok if I do this monday morning?


 Keep in minde we agreeded to a deadline to get this sorted and in shape
 to land by EOD monday or we will have to retain the old, and crappy fork
 method. If possible please work out how this needs to work as early as
 possible so Alex can continue.


 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a
 separate script so as to make it possible to use it wherever we need this
 (tests, builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next week we are
 going to switch building all the packages to perestroika. And in order 
 to
 gather upstream modules right before building fuel-library package, we 
 need
 to change perestroika build scripts.

 2) Currently we build packages using make system and you are right
 about the place where you need to make changes.
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 If you create shell script, I'll help you to add it to make code.




 I have updated my review[0] to extract the update logic to it's own
 bash script that can be invoked by the build scripts.  Let me know what
 would be the best way to wedge this in there.  I think for the
 perestroika this would also be needed for the fuel-library build, so if
 you point me at that I can see if I can help make that change as well.

 Thanks,
 -Alex

 [0] https://review.openstack.org/#/c/202763/



 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko 
 adide...@mirantis.com wrote:

 I believe build_repo function is the best way to do this [0]. So for
 fuel-library we'll need to run a shell script right from the repo before
 'touch $$@'. We can make it either conditional ( test -f
 ./path/additional_build_script.sh  bash 
 ./path/additional_build_script.sh
 ) or as additional parameter to function and add it in fuel-library call 
 [1]

 Regards,
 Alex

 [0]
 https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37
 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45


 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Alex,

 On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
 wrote:
 
  Hi,
 
  I think that we should provide a separate script that will fetch
 the upstream modules into fuel-library/deployment/puppet/ directory. It
 will allow us to have everything in a single place and use this script 
 in
 ISO build process and CI jobs.
 

 Right. That is what I'm going for. The issue I need help with is the
 best way to execute this as part of the build process.  From what i
 understand of the build process is that we are using git archive for all
 pieces so I'm not sure how to wedge in an extra script execution to do 
 the
 module fetch.  The creation of the script isn't the issue, the issue is 
 how
 can I properly run it as part of the build process.


  Regards,
  Alex
 

 Thanks,
 -Alex

  On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz 
 aschu...@mirantis.com wrote:
 
  Hello everyone,
 
  I have committed the initial configuration required to start
 leveraging librarian-puppet as part of the way we pull in upstream 
 puppet
 modules[0]. Additionally, I have also committed a change that would 
 pull in
 the openstack-ironic module[1].  The one piece that is missing from this
 being a complete solution is the ability to run librarian-puppet as 
 part of
 our build process for the fuel-library.  I've looked into the fuel-main
 build scripts and I think it's over my head to figure this out just by
 looking. Can anyone explain to me or assist me in how I could go about

[openstack-dev] [fuel] NodeGroups vs network-templates and static routes

2015-07-16 Thread Andrew Woodward
In 6.0 we added nodegroups as part of the multiple-cluster-networks
features. With these you can add additional sets of networks with so that
the nodes can exist on different network segments. When these are used you
will also need to set the gateway for each of your networks. When you do
this, you get routes set up between the matching network names across the
nodegroups.

For example network.yaml that looks like (shortened)

networks:
- cidr: 172.16.0.0/24
  gateway: 172.16.0.1
  group_id: 2
  id: 6
- cidr: 172.16.10.0/24
  gateway: 172.16.10.1
  group_id: 3
  id: 9

Will result in mappings like this in a nodes yaml (in nodegroup 2)

network_scheme:
  endpoints:
br-ex:
  IP:
  - 172.16.0.4/24
  routes:
  - net: 172.16.10.0/24
via: 172.16.0.1


With the introduction of templates we may no longer need nodegroups. They
served two functions. 1) They allowed us to create additional networks. 2)
They created additional routes between networks of the same name. Comparing
with what is in templates, #1 is taken care of, but what about #2? I think
that we need the routes configured anyway. Nodes with the same network role
should have a route for it when it crosses network segments.

This would have traditionally been separated by nodegroups. but it now can
be coded with templates. In this case (such as the yaml above) we must have
routes for the nodes to communicate on the correct interface. Since we need
code for routes between segments of the same network role, it might behoove
ourselves to compute (maybe not use when they are the local interface).
This serves two functions, it allows us to visualize the routing topology
instead of just relying on the default route. Secondly when we get to using
a routing protocol it gives us the data necessary to validate the routing
protocol with what we expected.

Regardless of computing all the routes, we need to compute same role, but
multi-segement routes. In this case I see that nodegroups becomes
redundant. It's only value is that it may be a simpler interface then
templates but it imposes the old network topology which I could see people
wanting to get away from.
-- 

--

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


Re: [openstack-dev] [fuel] Meeting July 16

2015-07-16 Thread Andrew Woodward
Meeting minutes are available at

http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-16-16.00.html

On Wed, Jul 15, 2015 at 3:36 PM Andrew Woodward xar...@gmail.com wrote:

 Please note the IRC meeting is scheduled for 16:00 UTC in
 #openstack-meeting-alt

 Please review meeting agenda and update if there is something you wish to
 discuss.

 https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community

-- 

--

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


Re: [openstack-dev] [Fuel] New Criteria for UX bugs

2015-07-15 Thread Andrew Woodward
I've updated the documentation on the wiki with this criteria

https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Confirm_and_triage_bugs

On Tue, Jul 14, 2015 at 4:22 PM Mike Scherbakov mscherba...@mirantis.com
wrote:

 Sounds good to start, we can always adjust later if needed. I actually
 changed one doc bug priority already using this criteria.

 On Fri, Jul 10, 2015 at 5:42 AM Jay Pipes jaypi...@gmail.com wrote:

 On 07/09/2015 06:14 PM, Andrew Woodward wrote:
  We often have bugs which create really poor User eXperience (UX) but our
  current bug priority criteria prevent nearly all of them from being
  higher than medium (as they nearly always have workarounds). We need to
  identify what should qualify as a critical, or high UX defect so that
  they can receive appropriate attention.
 
  We discussed what this may look like on the IRC meeting, the general
  idea here is that the complexity of effort to work around the UX issue
  should be related to the priority.
 
  Critical: requires massive effort to work around, including [un|under]
  documented commands and edits to config files
 
  High: requires modification of config files, interfaces that users
  aren't expected to use (ie the API when it's _intended_ to work in the
  CLI / UI (exclusive of interfaces that are intended to only be available
  via API) or requires custom node yaml (again except when it should
  exclusively be available)
 
  Medium: Straight forward commands in the CLI

 Above criteria look excellent to me, thanks Andrew!
 -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

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

-- 

--

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


[openstack-dev] [fuel] Meeting July 16

2015-07-15 Thread Andrew Woodward
Please note the IRC meeting is scheduled for 16:00 UTC in
#openstack-meeting-alt

Please review meeting agenda and update if there is something you wish to
discuss.

https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
-- 

--

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


Re: [openstack-dev] [fuel] Deprecation and backwards compaibility Policy

2015-07-15 Thread Andrew Woodward
Using lazy census here, I will update the wiki with this process.

On Mon, Jun 29, 2015 at 4:22 PM Andrew Woodward xar...@gmail.com wrote:

 Some recent specs have proposed changing some of the API's by either
 removing parts, or changing them in non-backwards way. Additionally there
 are some proposals that are light on details of their impact to already
 supported components.

 I propose that deprecation and backwards compatibility should be
 maintained for at least one release before removing support for the
 previous implementation.

 This would result in a process such as

 A - A2,B - B
 R1 - R2- R3

 Where
 A is the initial implementation
 A2 is the depricated A interface that likely converts to B back to A
 B is the new feature

 R[1,2,3] Releases incrementing.

 This would require that the interface A is documented in the release notes
 of R2 as being marked for removal. The A interface can then be removed in
 R3.

 This will allow for a reasonable time for down-stream users to learn that
 the interface they may be using is going away and they can adapt to the new
 interface before it's the only interface available.

 --

 --

 Andrew Woodward

 Mirantis

 Fuel Community Ambassador

 Ceph Community

-- 

--

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


Re: [openstack-dev] [Fuel] wrong network for keystone endpoint in 6.1 ?

2015-07-09 Thread Andrew Woodward
The is the expected, although security conservative approach to admin
endpoints in fuel, it does pretty much block all actions in keystone other
then auth from outside the cluster. It pre-dates me, and fuel 3.0.1; my
understanding of the intent here is that we don't want a compromise to
result in all kinds of accounts being created.

On Thu, Jul 9, 2015 at 3:35 PM Stanislaw Bogatkin sbogat...@mirantis.com
wrote:

 Hi Daniel,

 answer is no - actually there is no strong dependency between public and
 internal/admin endpoints. In your case keystone client ask keystone on
 address 10.52.71.39 (which, I think, was provided by system
 variable OS_AUTH_URL), auth on it and then keystone give endpoints list to
 client. Client selected admin endpoint from this list (192.168.20.3
 address) and tried to get information you asked. It's a normal behavior.

 So, in Fuel by default we have 3 different endpoints for keystone - public
 on public VIP, port 5000; internal on management VIP, port 5000, admin on
 management VIP, port 35357.

 On Thu, Jul 9, 2015 at 4:59 PM, Daniel Comnea comnea.d...@gmail.com
 wrote:

 Hi,

 I'm running Fuel 6.1 and i've seen an interesting behavior which i think
 match bug [1]

 Basically the adminUrl  publicUrl part of keystone endpoint are
 different

 And the result of that is that you can't run keystone cli - i.e
 create/list tenants etc

 keystone --debug tenant-list
 /usr/local/lib/python2.7/site-packages/keystoneclient/shell.py:65:
 DeprecationWarning: The keystone CLI is deprecated in favor of python-
 openstackclient. For a Python library, continue using python-keys
 toneclient.
   'python-keystoneclient.', DeprecationWarning)
 DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
 http://10.20.71.39:5000/v2.0/tokens
 INFO:requests.packages.urllib3.connectionpool:Starting new HTTP
 connection (1): 10.52.71.39
 DEBUG:requests.packages.urllib3.connectionpool:POST /v2.0/tokens
 HTTP/1.1 200 3709
 DEBUG:keystoneclient.session:REQ: curl -g -i -X GET
 http://192.168.20.3:35357/v2.0/tenants -H User-Agent: python-
 keystoneclient -H Accept: application/json -H X-Auth-Token:
 {SHA1}cc918b89c2dca563edda43e01964b1f1979c552b

 shouldn't adminURL = publicURL = br-ex for keystone?


 Dani


 [1] https://bugs.launchpad.net/fuel/+bug/1441855

 __
 OpenStack Development Mailing 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

-- 

--

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


[openstack-dev] [puppet] Supporting two openstack releases in the same puppet release

2015-07-09 Thread Andrew Woodward
It has come to my attention that we spend an enormous amount of time in
Fuel when switching between OpenStack releases. A good amount of this seems
to be due to a chicken and the egg problem. We cant deploy updated packages
with out updated manifests, and we we cant update (in that CI won't pass)
the manifests without updated packages. In order to accommodate this we
either have to set up a new separate set of CI pipelines for both or freeze
various parts of CI, merging patch sets that can't pass until everything is
in and working, or some monstrous combination of both. This has become
quite the time sink for everyone involved and there must be a better way to
accommodate switching between releases.

Thinking about this I wonder how much easier this process could be if the
manifests supported two releases at once.

I propose that we consider supporting both the dev release, and the prior
release (as stable and default for option precedence). We would need to
come up with some option versioning scheme in which we can identify options
which are only relevant to the specific release (I'm not yet sure what sure
what this would look line) This seems like it would be most of the need to
support multiple versions at once.

But why should we go through this effort? Yes this would become complicated
to set up, however I cant imagine that other folks are not having a similar
issues.

* Moving to a two version system should nearly reduce the impact of
switching to nearly none (given you have packages)
* It should also help accelerate our releases of puppet-openstack, since
devs can switch between versions more easily
* It should help our release support story since non-option changes will
automatically hit dev and (current) stable manifests at the same time
* This can also help the current stable release process, instead of
branching, we can simply tag the first stable release and maintain it in
the master branch, only pushing it out when we drop it to shift the
dev/stable versions
* While not a direct benefit to puppet-openstack, this would help simplify
fuel running CI on master openstack and master puppet-openstack which will
help with our efforts in puppet-openstack

So next steps
Lets discuss the proposal in general (good idea / bad idea). I'd like to
hash out what this versioned interface may need to look like, that way I
can take up attempting to make this work in a single module so we can
vet/discuss any issues more thoroughly.
-- 

--

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


  1   2   3   >