Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Yolanda Robla Mota]

I see another problem working on patchsets with lots of revisions and
long-lived history, such as specs or a complex change. The opinions of
several reviewers may be different. So first reviewer lefts a comment, the
owner of the change amends the patch according to it. But after time and
iterations pass (and because the history is very long or impossible to
read) another reviewer who has not read the whole history, may come and put
a -1 that contradicts the initial change. Things like that could be sorted
if we keep shorter patchsets, and merge things that are production ready
but not perfect, then we come up with follow-up patches to amend possible
comments, or create enhancements.

On Wed, May 30, 2018 at 4:16 PM, Dmitry Tantsur  wrote:

> On 05/30/2018 03:54 PM, Julia Kreger wrote:
>
>> On Tue, May 29, 2018 at 7:42 PM, Zane Bitter  wrote:
>> [trim]
>>
>>> Since I am replying to this thread, Julia also mentioned the situation
>>> where
>>> two core reviewers are asking for opposite changes to a patch. It is
>>> never
>>> ever ever the contributor's responsibility to resolve a dispute between
>>> two
>>> core reviewers! If you see a core reviewer's advice on a patch and you
>>> want
>>> to give the opposite advice, by all means take it up immediately - with
>>> *the
>>> other core reviewer*. NOT the submitter. Preferably on IRC and not in the
>>> review. You work together every day, you can figure it out! A random
>>> contributor has no chance of parachuting into the middle of that dynamic
>>> and
>>> walking out unscathed, and they should never be asked to.
>>>
>>>
>> Absolutely agree! In the case that was in mind where it has happened
>> to me personally, I think it was 10-15 revisions apart, so it becomes
>> a little hard to identify when your starting to play the game of "make
>> the cores happy to land it". It is not a fun game for the contributor.
>> Truthfully it caused me to add the behavior of intentionally waiting
>> longer between uploads of new revisions... which does not help at all.
>>
>> The other conundrum is when you disagree and the person has left a -1
>> which blocks forward progress and any additional reviews since it gets
>> viewed as "not ready", which makes it even harder and slower to build
>> consensus. At some point you get into "Oh, what formatting can I
>> change to clear that -1 because the person is not responding" mode.
>>
>
> This, by the way, is a much broader and interesting question. In case of a
> by-passer leaving a comment ("this link must be https") and disappearing,
> the PTL or any core can remove the reviewer from the review. What to do
> with a core leaving a comment or non-core leaving a potentially useful
> comment and going to PTO?
>
>
>
>> At least beginning to shift the review culture should help many of these
>> issues.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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] Proposing Mark Goddard to ironic-core

[Yolanda Robla Mota]

+1 .. his reviews have always been helpful to me

On Thu, May 24, 2018 at 7:57 AM, Shivanand Tendulker <stendul...@gmail.com>
wrote:

> +1 from me.
>
>
>
> On Sun, May 20, 2018 at 8:15 PM, Julia Kreger <juliaashleykre...@gmail.com
> > wrote:
>
>> Greetings everyone!
>>
>> I would like to propose Mark Goddard to ironic-core. I am aware he
>> recently joined kolla-core, but his contributions in ironic have been
>> insightful and valuable. The kind of value that comes from operative use.
>>
>> I also make this nomination knowing that our community landscape is
>> changing and that we must not silo our team responsibilities or ability to
>> move things forward to small highly focused team. I trust Mark to use his
>> judgement as he has time or need to do so. He might not always have time,
>> but I think at the end of the day, we’re all in that same boat.
>>
>> -Julia
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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] Proposing Marius Cornea core on upgrade bits

[Yolanda Robla Mota]

+1, Marius has been a great help

On Thu, Apr 19, 2018 at 7:01 PM, Emilien Macchi <emil...@redhat.com> wrote:

> Greetings,
>
> As you probably know mcornea on IRC, Marius Cornea has been contributing
> on TripleO for a while, specially on the upgrade bits.
> Part of the quality team, he's always testing real customer scenarios and
> brings a lot of good feedback in his reviews, and quite often takes care of
> fixing complex bugs when it comes to advanced upgrades scenarios.
> He's very involved in tripleo-upgrade repository where he's already core,
> but I think it's time to let him +2 on other tripleo repos for the patches
> related to upgrades (we trust people's judgement for reviews).
>
> As usual, we'll vote!
>
> Thanks everyone for your feedback and thanks Marius for your hard work and
> involvement in the project.
> --
> 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
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic][Bifrost] Manually enrolling a node

[Yolanda Robla Mota]

Hi Michael
So what does ironic driver-list say? May it be pxe_ipmitool? It would also
be useful if you provide the conductor logs.

On Sun, Mar 4, 2018 at 11:06 AM, Michael Still <mi...@stillhq.com> wrote:

> Heya,
>
> I've been playing with bifrost to help me manage some lab machines. I must
> say the install process was well documented and smooth, so that was a
> pleasure. Thanks!
>
> That said, I am struggling to get a working node enrolment. I'm resisting
> using the JSON file / ansible playbook approach, because I'll want to add
> more machines later so I need a manual enrolment to work. The command line
> I am using is like this:
>
> ironic node-create -d agent_ipmitool \
>-i ipmi_username=root \
>-i ipmi_password=superuser \
>-i ipmi_address=192.168.50.31 \
>-i deploy_kernel=http://192.168.50.209:8080/ipa.vmlinuz \
>-i deploy_ramdisk=http://192.168.50.209:8080/ipa.initramfs \
>-p cpus=16 \
>-p memory_mb=12288 \
>-p local_gb=750 \
>-p cpu_arch=x86_64 \
>-p capabilities=boot_option:local
>
> Unfortunately, I get this error:
>
> No valid host was found. Reason: No conductor service registered which
> supports driver agent_ipmitool. (HTTP 400)
>
> I can't see anything helpful in the logs. What driver should I be using
> for bifrost? agent_ipmitool seems to be enabled in ironic.conf.
>
> Thanks heaps,
> Michael
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Yolanda Robla Mota]

> Hmm, are we talking about IPA or user images? IPA always PXE boots, no
> matter what boot_option we use. For user images with boot_option=local our
> only bet is using the ansible deploy interface, I think (please review it!)
>

User images, i'm talking about user images (specifically about
overcloud-full image). I know ansible deploy driver will be an option, but
it will mean, that for booting from ISCSI with some specific hardware,
ansible deploy driver will be the only option possible. So exploring other
options as well, that could be simpler and will not restrict the driver.

>
>
> So, this is where the confusion probably is: "deployment image" is IPA.
> And by the way the IPA image used in TripleO is based on dracut.
>

That's specifically what made IPA agent work with ibft:

http://git.openstack.org/cgit/openstack/tripleo-image-elements/commit/?id=22a5e4e50f2bf2a71128614218ed208ee8f6f5c2

>
> If you're talking about instance or user image, then, as I mention above,
> the only option we have now is the ansible deploy interface.
>
>
>>
>>
>> Thanks
>>
>> --
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.com <mailto:yrobl...@redhat.com>
>> <mailto:yrobl...@redhat.com <mailto:yrobl...@redhat.com>> M:
>> +34605641639 <tel:%2B34605641639>
>> <http://redhatemailsignature-marketing.itos.redhat.com/
>> <http://redhatemailsignature-marketing.itos.redhat.com/>>
>>
>> <https://red.ht/sig>
>>
>>
>> 
>> __
>> 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:un
>> subscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
>> ck-dev>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> --
>>
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.com <mailto:yrobl...@redhat.com> M: +34605641639 <
>> http://redhatemailsignature-marketing.itos.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>> ____________
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Yolanda Robla Mota]

Answering inline...


Note that we only support BFV in the form of booting from a cinder volume
> officially. We haven't looked into iBFV in depth.
>

I have been testing that on the context of booting from SAN. It is at
deploy time, in the context of TripleO, in the undercloud. At that point no
cinder is there. We have been deploying with some ISCSI targets, and ironic
consuming those instead of booting from local hard disk. I guess it is a
different context.

>
>
> This has been discussed several times, and every time the idea of making
> it a generic feature was rejected. There is an option to configure kernel
> parameters for PXE boot. However, apparently, you cannot add
> rd.iscsi.firmware=1 if you don't use iSCSI, it will fail to boot (Derek
> told me that, I did not check). If your deployment only uses iSCSI - you
> can modify [pxe]pxe_append_params in your ironic.conf to include it.
>

No PXE boot possible. As it is in the context of TripleO, we use the
boot_option=local. I know that it is possible to customize with pxe boot,
but we cannot rely on it, but have the kernel parameter on local boot.

>
>
> Well, we could probably do that *for IPA only*. Something like
> driver_info/deploy_image_append_params. This is less controversial than
> doing that for user instances, as we fully control the IPA boot. If you
> want to work on it, let's start with a detailed RFE please.
>

IPA boot works fine. Some time ago I added some patches on the ironic-agent
element, to force the modprobe of several modules (including ibft, fcoe,
etc...) That is because IPA image is not based on dracut, so it doesn't
rely on parsing the cmdline from kernel boot and dracut hooks. The problem
with kernel parameters is only happening now on the deployment image, and
so far, the only working solution i could find, is execute a virt-customize
on the image to add those.

>
>
>> Thanks
>>
>> --
>>
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.com <mailto:yrobl...@redhat.com> M: +34605641639 <
>> http://redhatemailsignature-marketing.itos.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Yolanda Robla Mota]

Hi Julia
Yes, you are right on your assumptions here. The missing feature here, is
the ability of Ironic to provide a mechanism to append standard kernel
arguments, when not netbooting. Having a way to append default parameters
to bootloader would be very useful and avoid the need of manual hacks, and
shouldn't be difficult to implement because Ironic is already interacting
with the bootloader.
How could we progress on that? Is some spec needed to provide this feature?

On Mon, Oct 16, 2017 at 9:29 PM, Julia Kreger <juliaashleykre...@gmail.com>
wrote:

> Greetings Yolanda!
>
> I guess I'm slightly not clear. In fact, I may be slightly even more
> confused since we've discussed this directly. Thinking out loud, there are
> two different scenarios of booting from iSCSI.
>
> 1) Human created/assigned/associated LUN off of a SAN which we want a node
> to boot from, and that LUN lives onward as the "storage" for the node.
>
> 2) Cinder facilitated LUN off of $something that we want a node to boot
> from. This largely would be the logic we added this past cycle to support
> either booting via iPXE to iSCSI, or in the case of the iRMC driver, to set
> the HBA to boot/attach from specific volumes.
>
> I think your largely bringing up the first case when we speak of booting
> from iSCSI. If not, then we technically haven't reached the point where we
> are explicitly supporting hardware HBA use, but no time like the present!
>
> Since there are many things here, I think we need to make sure we are
> contextually on the same page. If any of this is wrong, please correct me:
>
> * You deploying a partition/filesystem image.
> * Ironic is partitioning and executing the installation of grub.
> * The scenario where your operating requires the boot loader command line
> to be updated with specific arguments.
> * Part of the problem is the ramdisk initialization where it is only
> honors arguments in your specific case.
> * Ironic does not presently provide a mechanism to append standard kernel
> arguments outside of netboot. Example from ages ago that many may remember,
> having to add ``noapic`` in some cases with a SMP kernel is to be used.
>
> I believe it makes sense to have some sort of mechanism to append to the
> default list in this case. There is the ansible deploy driver, but it seems
> like that might be overkill for setting boot loader parameters, and Ironic
> is explicitly executing grub-isntall.
>
> I think the only reason we've resisted in supporting updating the defaults
> file the past is because it would mean explicitly writing data to the grub
> defaults file on the filesystem, I suspect our comfort level with
> supporting that now may be different. In hindsight, considering we
> essentially already support this with netboot but not local boot with a
> partition image, I think we should add support for appending default
> parameters.
>
> Thoughts?
>
> -Julia
>
>
> On Mon, Oct 16, 2017 at 2:06 AM, Yolanda Robla Mota <yrobl...@redhat.com>
> wrote:
>
>> Hi
>> Recently i've been helping some customers in the boot from ISCSI feature.
>> So far everything was working, but we had a problem when booting the
>> deployment image.
>> It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
>> grub commands. But as the generated deployment image doesn't contain these
>> flags, ISCSI was not booting properly. For other hardware setups, different
>> flags may be needed.
>> The solution was to manually execute a virt-customize on the deployment
>> image to hardcode these parameters.
>> I wonder if we can add some feature in Ironic to support it. We have
>> discussed about kernel parameters several times. But at this time, it
>> affects ISCSI booting. Not having a way in Ironic to customize these
>> parameters forces to manual workarounds.
>> So can we reconsider the proposal to add kernel parameters there? It
>> could be a settable argument (driver_info/kernel_args), and then the IPA
>> could set the parameters properly on the image. Or any other option is
>> welcome.
>> What are your thoughts there?
>>
>> Thanks
>>
>> --
>>
>> Yolanda Robla Mota
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>>
>> C/Avellana 213
>>
>> Urb Portugal
>>
>> yrobl...@redhat.comM: +34605641639
>> <http://redhatemailsignature-marketing.itos.redhat.com/>
>> <https://red.ht/sig>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsub

[openstack-dev] [ironic] Kernel parameters needed to boot from iscsi

[Yolanda Robla Mota]

Hi
Recently i've been helping some customers in the boot from ISCSI feature.
So far everything was working, but we had a problem when booting the
deployment image.
It needed specifically a flag rd.iscsi.ibft=1 rd.iscsi.firmware=1 in the
grub commands. But as the generated deployment image doesn't contain these
flags, ISCSI was not booting properly. For other hardware setups, different
flags may be needed.
The solution was to manually execute a virt-customize on the deployment
image to hardcode these parameters.
I wonder if we can add some feature in Ironic to support it. We have
discussed about kernel parameters several times. But at this time, it
affects ISCSI booting. Not having a way in Ironic to customize these
parameters forces to manual workarounds.
So can we reconsider the proposal to add kernel parameters there? It could
be a settable argument (driver_info/kernel_args), and then the IPA could
set the parameters properly on the image. Or any other option is welcome.
What are your thoughts there?

Thanks

-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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][DIB] how create triplo overcloud image with latest kernel?

[Yolanda Robla Mota]

If you need a guideline about how to build TripleO images with DIB, i have
that blogpost:
http://teknoarticles.blogspot.com.es/2017/07/build-and-use-security-hardened-images.html

This if for security hardened images, but your replace
"overcloud-hardened-images" by "overcloud-images", it will build the
default one. You can specify the base image you want to use, as well as
enable any repo you have, that may take the latest kernel.

Hope it helps!

On Wed, Sep 27, 2017 at 5:21 PM, Brad P. Crochet <b...@redhat.com> wrote:

>
> On Tue, Sep 26, 2017 at 2:58 PM Ben Nemec <openst...@nemebean.com> wrote:
>
>>
>>
>> On 09/26/2017 05:43 AM, Moshe Levi wrote:
>> > Hi all,
>> >
>> > As part of the OVS Hardware Offload [1] [2],  we need to create new
>> > Centos/Redhat 7 image  with latest kernel/ovs/iproute.
>> >
>> > We tried to use virsh-customize to install the packages and we were able
>> > to update iproute and ovs, but for the kernel there is no space.
>> >
>> > We also tried with virsh-customize to uninstall the old kenrel but we no
>> > luck.
>> >
>> > Is other ways to replace kernel  package in existing image?
>>
>> Do you have to use an existing image?  The easiest way to do this would
>> be to create a DIB element that installs what you want and just include
>> that in the image build in the first place.  I don't think that would be
>> too difficult to do now that we're keeping the image definitions in
>> simple YAML files.
>>
>>
> If it is just packages, a DIB element wouldn't even be necessary. You
> could define a new yaml that just adds the packages that you want, and add
> that to the CLI when you build the images.
>
>
>> >
>> > [1] - https://review.openstack.org/#/c/504911/
>> > <https://emea01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F504911%2F=02%7C01%
>> 7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%
>> 7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=
>> 6oEmh0LJacV3WPGGp3wW%2BhL3nPDxRh%2BzNPY67X09Blc%3D=0>
>> >
>> >
>> > [2] - https://review.openstack.org/#/c/502313/
>> > <https://emea01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Freview.openstack.org%2F%23%2Fc%2F502313%2F=02%7C01%
>> 7Cmoshele%40mellanox.com%7Cc801dab0778b428e226508d504c97ecf%
>> 7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636420185839119329=
>> EsydZ9EsUjkYcF92Gys569SJEvQ%2B%2Fu6uV8WAQJ0YMfc%3D=0>
>> >
>> >
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS
> Principal Software Engineer
> (c) 704.236.9385 <(704)%20236-9385>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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] Proposing Saravanan KR core

[Yolanda Robla Mota]

+1 from my side!
Saravanan is part of our team, and he is brilliant. He is one of our team
gurus when talking about TripleO and NFV integration. From our NFVPE point
of view, it will be great and well deserved, that Saravanan becomes core.

On Fri, Jul 21, 2017 at 5:01 PM, Emilien Macchi <emil...@redhat.com> wrote:

> Saravanan KR has shown an high level of expertise in some areas of
> TripleO, and also increased his involvement over the last months:
> - Major contributor in DPDK integration
> - Derived parameter works
> - and a lot of other things like improving UX and enabling new
> features to improve performances and networking configurations.
>
> I would like to propose Saravanan part of TripleO core and we expect
> his particular focus on t-h-t, os-net-config and tripleoclient for now
> but we hope to extend it later.
>
> As usual, we'll vote :-)
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Ansible] Proposing Markos Chandras for osa-core

[Yolanda Robla Mota]

+1!
I work with Markos in other OPNFV projects, and he is great.

On Tue, Jul 18, 2017 at 11:57 AM, Jean-Philippe Evrard <
jean-phili...@evrard.me> wrote:

> +1 Thanks for all the work!
>
> On Tue, Jul 18, 2017 at 10:33 AM, Nicolas Bock <
> nicolasbock.openst...@gmail.com> wrote:
>
>> On Tue, Jul 18, 2017 at 10:23:46AM +0100, Andy McCrae wrote:
>>
>>> Following on from last week's meeting I'd like to propose Markos
>>> (hwoarang)
>>> for OSA core.
>>>
>>
>> +1 !!
>>
>> Markos has done a lot of good reviews and commits over an extended period
>>> of time, and has shown interest in the project as a whole. (Not to
>>> mention
>>> the addition of SUSE support)
>>>
>>> We already have quite a few +1's from the meeting itself, but opening up
>>> to
>>> everybody who wasn't available at the meeting!
>>>
>>> Thanks,
>>> Andy
>>>
>>
>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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] Forming our plans around Ansible

[Yolanda Robla Mota]

What i'd like to dig more is how Ansible and Heat can live together. And
what features do Heat offer that are not covered by Ansible as well? Is
there still the need to have Heat as the main engine, or could that be
replaced by Ansible totally in the future?

On Sat, Jul 8, 2017 at 12:20 AM, James Slagle <james.sla...@gmail.com>
wrote:

> On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard <d...@redhat.com>
> wrote:
> > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.sla...@gmail.com>
> wrote:
> >> (0) tripleo-quickstart which follows the common and well accepted
> >> approach to bundling a set of Ansible playbooks/roles.
> >
> > I don't want to de-rail the thread but I really want to bring some
> > attention to a pattern that tripleo-quickstart has been using across
> > it's playbooks and roles.
> > I sincerely hope that we can find a better implementation should we
> > start developing new things from scratch.
>
> Yes, just to clarify...by "well accepted" I just meant how the git
> repo is organized and how you are expected to interface with those
> playbooks and roles as opposed to what those playbooks/roles actually
> do.
>
> > I'll sound like a broken record for those that have heard me mention
> > this before but for those that haven't, here's a concrete example of
> > how things are done today:
> > (Sorry for the link overload, making sure the relevant information is
> available)
> >
> > For an example tripleo-quickstart job, here's the console [1] and it's
> > corresponding ARA report [2]:
> > - A bash script is created [3][4][5] from a jinja template [6]
> > - A task executes the bash script [7][8][9]
>
> From my limited experience, I believe the intent was that the
> playbooks should do what a user is expected to do so that it's as
> close to reproducing the user interface of TripleO 1:1.
>
> For example, we document users running commands from a shell prompt.
> Therefore, oooq ought to do the same thing as close as possible.
> Obviously there will be gaps, just as there is with tripleo.sh, but I
> feel that both tools (tripleo.sh/oooq) were trying to be faithful to
> our published docs as mush as possible, and I think there's something
> to be commended there.
>
> Not saying it's right or wong, just that I believe that was the intent.
>
> An alternative would be custom ansible modules that exposed tasks for
> interfacing with our API directly. That would also be valuable, as
> that code path is mostly untested now outside of the UI and CLI.
>
> I think that tripleo-quickstart is a slightly different class of
> "thing" from the other current Ansible uses I mentioned, in that it
> sits at a layer above everything else. It's meant to automate TripleO
> itself vs TripleO automating things. Regardless, we should certainly
> consider how it fits into a larger plan.
>
> --
> -- James Slagle
> --
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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] [diskimage-builder] Restarting bi-weekly meeting

[Yolanda Robla Mota]

This time is super complicated to me , as it's night here. Ideally i'd
prefer early morning on UTC time, but I understand this may be a problem
for people in another timezones.

On Fri, May 26, 2017 at 7:42 AM, Ian Wienand <iwien...@redhat.com> wrote:

> Hi,
>
> We've let this meeting [1] lapse, to our communications detriment.  I
> will restart it, starting next week [2].  Of course agenda items are
> welcome, otherwise we will use it as a session to make sure patches
> are moving in the right direction.
>
> If the matter is urgent, and not getting attention, an agenda item in
> the weekly infra meeting would be appropriate.
>
> Ping me off list if you're interested but this time doesn't work.  If
> there's a few, we can move it.
>
> Thanks,
>
> -i
>
> [1] http://eavesdrop.openstack.org/#Diskimage_Builder_Team_Meeting
> [2] https://review.openstack.org/468270
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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] Undercloud backup and restore

[Yolanda Robla Mota]

Hi Carlos
A common request that i hear, is that customers need a way to rollback or
downgrade a system after an upgrade. So that will be useful of course. What
about the overcloud, are you considering that possibility? If they find
that an upgrade on a controller node breaks something for example.

On Wed, May 24, 2017 at 9:26 AM, Carlos Camacho Gonzalez <
ccama...@redhat.com> wrote:

> Hey folks,
>
> Based on what we discussed yesterday in the TripleO weekly team meeting,
> I'll like to propose a blueprint to create 2 features, basically to backup
> and restore the Undercloud.
>
> I'll like to follow in the first iteration the available docs for this
> purpose [1][2].
>
> With the addition of backing up the config files on /etc/ specifically to
> be able to recover from a failed Undercloud upgrade, i.e. recover the repos
> info removed in [3].
>
> I'll like to target this for P as I think I have enough time for
> coding/testing these features.
>
> I already have created a blueprint to track this effort
> https://blueprints.launchpad.net/tripleo/+spec/undercloud-backup-restore
>
> What do you think about it?
>
> Thanks,
> Carlos.
>
> [1]: https://access.redhat.com/documentation/en-us/red_hat_
> enterprise_linux_openstack_platform/7/html/back_up_and_
> restore_red_hat_enterprise_linux_openstack_platform/restore
>
> [2]: https://docs.openstack.org/developer/tripleo-docs/post_
> deployment/backup_restore_undercloud.html
>
> [3]: https://docs.openstack.org/developer/tripleo-docs/
> installation/updating.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (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] [tripleo] Feedback needed on sizing partitions

[Yolanda Robla Mota]

Hi
As part of the security hardened images effort:
https://blueprints.launchpad.net/tripleo/+spec/build-whole-disk-images

I created a patch to define the initial partitions on the image:
https://review.openstack.org/#/c/449122/7/elements/overcloud-secure/block-device-config.yaml

I tested those on a tripleo deployment for newton, and everything works
fine. But I really want feedback on the right sizing, specially for
production. So I'd like to get feedback from people working in tripleo, to
validate the sizes of partitions, and give advice on the right sizing there.

This work needs to land for Pike , so we don't have many time, I'd
appreciate collaboration. Thanks!

-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-l2gw] Unable to create release tag

[Yolanda Robla Mota]

Hi, seems the ACL is not correctly applied. infra-root as looking at it

Best
Yolanda

On Thu, Mar 23, 2017 at 5:18 PM, Gary Kotton <gkot...@vmware.com> wrote:

> Hi,
> I have tried updating my gpg key and still nothing works:
>
> gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
> Enter passphrase for key '/home/gkotton/.ssh/id_rsa':
> Counting objects: 1, done.
> Writing objects: 100% (1/1), 531 bytes | 0 bytes/s, done.
> Total 1 (delta 0), reused 0 (delta 0)
> remote: Processing changes: refs: 1, done
> To ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
> error: failed to push some refs to 'ssh://garyk@review.openstack.
> org:29418/openstack/networking-l2gw.git'
>
> Any idea here?
> This is blocking people who want to package…
> Thanks
> Gary
>
> On 3/21/17, 7:18 PM, "Gary Kotton" <gkot...@vmware.com> wrote:
>
> Hi,
> I am still unable to do this – this is after
> https://review.openstack.org/#/c/447279/ landed.
> Any ideas?
> Thanks
> Gary
>
> On 3/14/17, 3:04 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:
>
> On 2017-03-14 05:39:35 + (+), Gary Kotton wrote:
> > I was asked to create a release tag for stable/ocata. This fails
> with:
> [...]
> >  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
> [...]
>
> The ACL for that repo doesn't seem to be configured to allow it
> (yet):
>
> http://git.openstack.org/cgit/openstack-infra/project-
> config/tree/gerrit/acls/openstack/networking-l2gw.config
>
> The Infra Manual section documenting that permission is:
>
> https://docs.openstack.org/infra/manual/creators.html#
> creation-of-tags
>
> It also may be helpful to review the section on manually tagging
> releases:
>
> https://docs.openstack.org/infra/manual/drivers.html#
> tagging-a-release
>
> Hope that helps!
> --
> Jeremy Stanley
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCSA

Red Hat

<https://www.redhat.com>

C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639
<http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
__
OpenStack Development Mailing 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][diskimage-builder] Status of diskimage-builder

[Yolanda Robla Mota]

As user and contributor for diskimage-builder, i think that being an
independent project, and moving to the big tent, will benefit it. +1 from
my side

On Fri, Mar 3, 2017 at 2:35 AM, Matthew Thode <prometheanf...@gentoo.org>
wrote:

> On 03/02/2017 03:31 PM, Emilien Macchi wrote:
> >>> 1) Move diskimage-builder into own (big tent?) project. Setup a new
> PTL,
> >>> etc.
> > Let's move forward with this one if everybody agrees on that.
> >
> > DIB folks: please confirm on this thread that you're ok to move out
> > DIB from TripleO and be an independent project.
> > Also please decide if we want it part of the Big Tent or not (it will
> > require a PTL).
> >
> >>> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> > I don't think Infra wants to carry this one.
> >
> >>> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
> > We don't want to carry this one anymore for the reasons mentioned in
> > that thread.
> >
>
> As a sometimes contributor to DIB for Gentoo stuff I'm fine with moving
> it out into it's own project under the big tent, with a PTL and all.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639
__
OpenStack Development Mailing 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] [security] FIPS compliance

[Yolanda Robla Mota]

I completely agree that this shall be upstream first. So the main effort
will be on landing this python patch first. This has been up since 2010, so
more effort in terms of code contribution and reviews is needed, I'm happy
to collaborate in amending the patch as the reviews are requesting.

But the general idea is still there, and that's why a wrapper can make
sense. Even if the final patch has a different signature, or a different
functionality, the idea is the same: don't block md5 if that's not used for
security.

Even if the python patch lands, this would be in 3.7 and this version
adoption can take long in OpenStack. And enabling FIPS kernel is an
important security feature that we shall cover, if we just wait for the
patch to land it can take long time. The wrapper can be the short-term
solution as Doug says, allowing us to enable this important feature.

On Tue, Jan 17, 2017 at 5:51 PM, Doug Hellmann <d...@doughellmann.com>
wrote:

> Excerpts from Ian Cordasco's message of 2017-01-17 05:59:13 -0600:
> > On Tue, Jan 17, 2017 at 4:11 AM, Yolanda Robla Mota <yrobl...@redhat.com>
> wrote:
> > > Hi, in previous threads, there have been discussions about enabling
> FIPS,
> > > and the problems we are hitting with md5 inside OpenStack:
> > > http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107035.html
> > >
> > > It is important from a security perspective to enable FIPS, however
> > > OpenStack cannot boot with that, because of the existence of md5 calls
> in
> > > several projects. These calls are not used for security, just for hash
> > > generation, but even with that, FIPS is blocking them.
> > >
> > > There is a patch proposed for newest versions of python, to avoid that
> > > problem. The idea is that when a hash method is called, users could
> specify
> > > if these are used for security or not. If the useforsecurity flag is
> set to
> > > False, FIPS won't block the call. See: http://bugs.python.org/
> issue9216
> >
> > This patch looks to have died off in 2013 prior to Robert's comment from
> today.
> >
> > > This won't land until next versions of Python, however the patch is
> already
> > > on place for current RHEL and CentOS versions that are used in
> OpenStack
> > > deploys. Using that patch as a base, I have a proposal to allow FIPS
> > > enabling, at least in the distros that support it.
> > >
> > > The idea is to create a wrapper around md5, something like:
> > > md5_wrapper('string_to_hash', useforsecurity=False)
> >
> > We should probably work harder on actually landing the patch in Python
> > first. I agree with Robert that the optional boolean parameter is
> > awkward. It'd be better to have a fips submodule.
>
> Please see my comment on that patch about why that approach doesn't
> solve the problem.
>
> > > This method will check the signature of hashlib.md5, and see if that's
> > > offering the useforsecurity parameter. If that's offered, it will pass
> the
> > > given parameter from the wrapper. If not, we will just call
> > > md5('string_to_hash') .
> > >
> > > This gives us the possibility to whitelist all the md5 calls, and
> enabling
> > > FIPS kernel booting without problems. It will start to work for distros
> > > supporting it, and it will be ready to use generally when the patch
> lands in
> > > python upstream and another distros adopt it. At some point, when all
> > > projects are using newest python versions, this wrapper could
> disappear and
> > > use md5 useforsecurity parameter natively.
> >
> > I'd much rather have the upstream interface fixed in Python and then
> > to have a wrapper that does things the correct way. Otherwise, we're
> > encouraging other distros to use a patch that still requires a lot of
> > edits to address the review comments and might be defining an API that
> > will never end up in Python.
> >
> > > The steps needed to achieve it are:
> > > - create a wrapper, place it on some existing project or create a new
> fips
> > > one
> > > - search and replace all md5 calls used in OpenStack core projects ,
> to use
> > > that new wrapper. Note that all the md5 calls will be whitelisted by
> > > default. We have not noted any md5 call that is used for security, but
> if
> > > that exists, it shall be better to use another algorithms, in terms of
> > > security.
> > >
> > > What do people think about it?
> >
> > I think people should work on the Python patches *first*. Once they're
&g

[openstack-dev] [security] FIPS compliance

[Yolanda Robla Mota]

Hi, in previous threads, there have been discussions about enabling FIPS,
and the problems we are hitting with md5 inside OpenStack:
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107035.html

It is important from a security perspective to enable FIPS, however
OpenStack cannot boot with that, because of the existence of md5 calls in
several projects. These calls are not used for security, just for hash
generation, but even with that, FIPS is blocking them.

There is a patch proposed for newest versions of python, to avoid that
problem. The idea is that when a hash method is called, users could specify
if these are used for security or not. If the useforsecurity flag is set to
False, FIPS won't block the call. See: http://bugs.python.org/issue9216

This won't land until next versions of Python, however the patch is already
on place for current RHEL and CentOS versions that are used in OpenStack
deploys. Using that patch as a base, I have a proposal to allow FIPS
enabling, at least in the distros that support it.

The idea is to create a wrapper around md5, something like:
md5_wrapper('string_to_hash', useforsecurity=False)

This method will check the signature of hashlib.md5, and see if that's
offering the useforsecurity parameter. If that's offered, it will pass the
given parameter from the wrapper. If not, we will just call
md5('string_to_hash') .

This gives us the possibility to whitelist all the md5 calls, and enabling
FIPS kernel booting without problems. It will start to work for distros
supporting it, and it will be ready to use generally when the patch lands
in python upstream and another distros adopt it. At some point, when all
projects are using newest python versions, this wrapper could disappear and
use md5 useforsecurity parameter natively.

The steps needed to achieve it are:
- create a wrapper, place it on some existing project or create a new fips
one
- search and replace all md5 calls used in OpenStack core projects , to use
that new wrapper. Note that all the md5 calls will be whitelisted by
default. We have not noted any md5 call that is used for security, but if
that exists, it shall be better to use another algorithms, in terms of
security.

What do people think about it?

Best

-- 
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639
__
OpenStack Development Mailing 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][diskimage-builder] Status of diskimage-builder

[Yolanda Robla Mota]

>From my point of view, i've been using that either on infra with
puppet-infracloud, glean.. and now with TripleO. So in my opinion, it shall
be an independent project, with core contributors from both sides.

On Thu, Jan 12, 2017 at 8:51 PM, Paul Belanger <pabelan...@redhat.com>
wrote:

> On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
> > On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi <emil...@redhat.com>
> wrote:
> > > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger <pabelan...@redhat.com>
> wrote:
> > >> Greetings,
> > >>
> > >> With the containerization[1] of tripleo, I'd like to know more about
> the future of
> > >> diskimage-builder as it relates to the tripleo project.
> > >>
> > >> Reading the recently approved spec for containers, container (image)
> builds are
> > >> no longer under the control of tripleo; by kolla. Where does this
> leave
> > >> diskimage-builder as a project under tripleo?  I specifically ask,
> because I'm
> > >> wanting to start down the path of using diskimage-builder as an
> interface to
> > >> containers.
> > >>
> > >> Basically, is it time to move diskimage-builder out from the tripleo
> project
> > >> into another, or its own? Or is tripleo wanting to more forward on
> development
> > >> efforts on diskimage-builder.
> > >
> > > Looking at stats on who is actively contributing into DIB:
> > > http://stackalytics.com/?module=diskimage-builder
> > >
> > > It seems that we have some folks from infra and some folks on dib
> > > only, and a few contributors from TripleO.
> > >
> > > I guess the best option is to ask DIB contributors: do you want to own
> > > the project you're committing to?
> > > If not, is it something that should stay in TripleO (imo no) or move
> > > into openstack-infra (imo yes, if infra agrees).
> > >
> > > With my PTL hat, I'm really open to this thing and I wouldn't mind to
> > > transfer ownership to another group.
> >
> > I was under the impression it was already it's own project team based on:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html
> >
> > It looks like the change was never made in governance however.
> >
> Yes, it just looks like Greg created new core reviewers, not officially
> breaking
> away from tripleo.
>
> If everybody is on board with moving diskimage-builder outside of tripleo,
> we
> need to decided where it lives. Two options come to mind:
>
> 1) Move diskimage-builder into own (big tent?) project. Setup a new PTL,
> etc.
> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
>
> Thoughts?
>
> > The reason I -1'd Paul's TripleO spec and suggested it be proposed to
> > diskimage-builder was due to:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html
> and
> > https://review.openstack.org/#/c/336109/
> >
> > I just want to make sure the right set of reviewers who are driving
> > dib development see the spec proposal.
> >
> > --
> > -- James Slagle
> > --
> >
> > 
> __________
> > OpenStack Development Mailing List (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
>



-- 
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639
__
OpenStack Development Mailing 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] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Yep, what Saravanan said is fine.
The idea i had on mind, is to drop the config on /etc/default/grub, so when
ironic deploys the image and installs grub, the parameters are applied
properly. We did some POCs with that in the past, and Ironic was booting
the images with the right kernel params.
The documentation you talk about is how to do it now, but we have the hope
it can change, because reboots can be problematic under some environments
in production.

On Tue, Dec 13, 2016 at 12:28 PM, Oliver Walsh <owa...@redhat.com> wrote:

> Hi Saravanan,
>
> Ah, ok. I'd assumed ironic didn't touch the bootloader as the docs
> show a mkconfig & reboot to customize grub for localboot:
> http://docs.openstack.org/project-install-guide/
> baremetal/draft/advanced.html#appending-kernel-parameters-
> to-boot-instances.
>
> Thanks,
> Ollie
>
> On 13 December 2016 at 11:03, Saravanan KR <skram...@redhat.com> wrote:
> > Hi Oliver,
> >
> > During the deployment, Ironic will start the node with IPA ramdisk,
> > which will copy the overcloud image to the node's disk, then configure
> > the grub cfg [1], set the node to local boot and reboot the node.
> > After which the node will be boot with the overcloud image. So no
> > reboot required in the overcloud image, as the "deploy steps" will be
> > run by the IPA itself.
> >
> > Regards,
> > Saravanan KR
> >
> > [1] https://github.com/openstack/ironic-python-agent/blob/
> master/ironic_python_agent/extensions/image.py#L136
> >
> >
> > On Tue, Dec 13, 2016 at 4:18 PM, Oliver Walsh <owa...@redhat.com> wrote:
> >> Hi Yolanda,
> >>
> >>> these changes will be created by ironic before the image is deployed
> >>
> >> The question I'm asking is how are the changed created without a reboot?
> >>
> >> Typically when setting this via a manual change or via tuned the
> >> process is to modify /etc/default/grub, run grub2-mkconfig, and then
> >> reboot. Are you suggesting we drop in a pre-build grub cfg before
> >> deployment?
> >>
> >> Thanks,
> >> Ollie
> >>
> >> On 13 December 2016 at 10:33, Yolanda Robla Mota <yrobl...@redhat.com>
> wrote:
> >>> It won't need a reboot, because these changes will be created by ironic
> >>> before the image is deployed. So it will boot with the right
> parameters. The
> >>> alternative of doing with puppet after the image was deployed, needed a
> >>> reboot, because the changes were done post-deploy.
> >>> So ironic build steps are pre-deploy without reboot, puppet changes are
> >>> post-deploy with a reboot.
> >>>
> >>> On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh <owa...@redhat.com>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Saravanan wrote:
> >>>> > If ironic "deploy steps" can configure this "tuned" setting and run
> the
> >>>> > command
> >>>>
> >>>> How does this avoid the reboot?
> >>>>
> >>>> Yolanda wrote:
> >>>> > The idea will be to define custom deployment steps for ironic, like
> >>>> > including the kernel boot parameters.
> >>>>
> >>>> Again, is this avoiding the reboot or just moving it?
> >>>>
> >>>> Thanks,
> >>>> Ollie
> >>>>
> >>>> On 13 December 2016 at 09:02, Saravanan KR <skram...@redhat.com>
> wrote:
> >>>> > Hi Yolanda,
> >>>> >
> >>>> > The flow for "tuned" will be like set the "tuned" configuration
> files,
> >>>> > and then activate the profile by running the command "tuned-adm
> >>>> > tuned-profile-nfv". This command will actually write the required
> >>>> > configuration files for tuning the host. If ironic "deploy steps"
> can
> >>>> > configure this "tuned" setting and run the command, then it is good
> >>>> > enough.
> >>>> >
> >>>> > Regards,
> >>>> > Saravanan KR
> >>>> >
> >>>> > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota
> >>>> > <yrobl...@redhat.com> wrote:
> >>>> >> Hi Saravanan
> >>>> >> Thanks for your comments. With this new module, I guess a reboot is
> >>>> >> still
> >>>> >

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

It won't need a reboot, because these changes will be created by ironic
before the image is deployed. So it will boot with the right parameters.
The alternative of doing with puppet after the image was deployed, needed a
reboot, because the changes were done post-deploy.
So ironic build steps are pre-deploy without reboot, puppet changes are
post-deploy with a reboot.

On Tue, Dec 13, 2016 at 11:24 AM, Oliver Walsh <owa...@redhat.com> wrote:

> Hi,
>
> Saravanan wrote:
> > If ironic "deploy steps" can configure this "tuned" setting and run the
> command
>
> How does this avoid the reboot?
>
> Yolanda wrote:
> > The idea will be to define custom deployment steps for ironic, like
> including the kernel boot parameters.
>
> Again, is this avoiding the reboot or just moving it?
>
> Thanks,
> Ollie
>
> On 13 December 2016 at 09:02, Saravanan KR <skram...@redhat.com> wrote:
> > Hi Yolanda,
> >
> > The flow for "tuned" will be like set the "tuned" configuration files,
> > and then activate the profile by running the command "tuned-adm
> > tuned-profile-nfv". This command will actually write the required
> > configuration files for tuning the host. If ironic "deploy steps" can
> > configure this "tuned" setting and run the command, then it is good
> > enough.
> >
> > Regards,
> > Saravanan KR
> >
> > On Tue, Dec 13, 2016 at 1:04 PM, Yolanda Robla Mota <yrobl...@redhat.com>
> wrote:
> >> Hi Saravanan
> >> Thanks for your comments. With this new module, I guess a reboot is
> still
> >> needed after os-host-config ?
> >> Right now we have been guided by TripleO and Ironic people to start
> using
> >> what in Ironic is called "custom deployment steps". An initial spec is
> >> reflected here:
> >> https://review.openstack.org/#/c/382091
> >>
> >> The idea will be to define custom deployment steps for ironic, like
> >> including the kernel boot parameters. Can that be a solution for your
> >> "tuned" needs as well?
> >>
> >> Best
> >> Yolanda
> >>
> >> On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR <skram...@redhat.com>
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Thanks Yolanda for starting the thread. The list of requirements in
> >>> the host configuration, related to boot parameters and reboot are:
> >>>
> >>> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
> >>> mandatory, which has to be configured before os-net-config runs
> >>> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
> >>> update the boot parameters and a reboot is required
> >>> * Other items mentioned by Yolanda
> >>>
> >>> If it is configuring only, the boot parameters, then ironic's deploy
> >>> feature may help, but there are other requirement to enable the
> >>> "tuned" profile which tunes the host for the required configuration,
> >>> which also requires reboot, as it will alter the boot parameters. If
> >>> we can collate the all the configurations which requires reboot
> >>> together, we will improve the reboot time. And if we reboot before the
> >>> actual openstack services are started, then the reboot time _may_
> >>> improve.
> >>>
> >>> Can I propose a *new* module for TripleO deployments, like >
> >>> os-host-config <, which will run after os-collect-config and before
> >>> os-net-config, then we can collate all the host specific configuration
> >>> inside this module. This module can be a set of ansible scripts, which
> >>> will only configure the host. Ofcource the parameter to this module
> >>> should be provided via os-collect-config. Separating the host
> >>> configuration will help in the containerized TripleO deployment also.
> >>>
> >>> Or any other better alternatives are welcome.
> >>>
> >>> Please pour in your views if you think for/against it.
> >>>
> >>> Regards,
> >>> Saravanan KR
> >>>
> >>>
> >>> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota <
> yrobl...@redhat.com>
> >>> wrote:
> >>> > Hi , Dmitry
> >>> > That's what i didn't get very clear. If all the deployment steps are
> >>> > pre-imaging as that statement says, or every deploy step cou

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Hi Saravanan
Thanks for your comments. With this new module, I guess a reboot is still
needed after os-host-config ?
Right now we have been guided by TripleO and Ironic people to start using
what in Ironic is called "custom deployment steps". An initial spec is
reflected here:
https://review.openstack.org/#/c/382091

The idea will be to define custom deployment steps for ironic, like
including the kernel boot parameters. Can that be a solution for your
"tuned" needs as well?

Best
Yolanda

On Tue, Dec 13, 2016 at 7:59 AM, Saravanan KR <skram...@redhat.com> wrote:

> Hello,
>
> Thanks Yolanda for starting the thread. The list of requirements in
> the host configuration, related to boot parameters and reboot are:
>
> * DPDK - For vfio-pci driver binding, iommu support on kernel args is
> mandatory, which has to be configured before os-net-config runs
> * DPDK & RealTime - Enabling "tuned" profile for nfv or rt, will
> update the boot parameters and a reboot is required
> * Other items mentioned by Yolanda
>
> If it is configuring only, the boot parameters, then ironic's deploy
> feature may help, but there are other requirement to enable the
> "tuned" profile which tunes the host for the required configuration,
> which also requires reboot, as it will alter the boot parameters. If
> we can collate the all the configurations which requires reboot
> together, we will improve the reboot time. And if we reboot before the
> actual openstack services are started, then the reboot time _may_
> improve.
>
> Can I propose a *new* module for TripleO deployments, like >
> os-host-config <, which will run after os-collect-config and before
> os-net-config, then we can collate all the host specific configuration
> inside this module. This module can be a set of ansible scripts, which
> will only configure the host. Ofcource the parameter to this module
> should be provided via os-collect-config. Separating the host
> configuration will help in the containerized TripleO deployment also.
>
> Or any other better alternatives are welcome.
>
> Please pour in your views if you think for/against it.
>
> Regards,
> Saravanan KR
>
>
> On Fri, Dec 2, 2016 at 9:31 PM, Yolanda Robla Mota <yrobl...@redhat.com>
> wrote:
> > Hi , Dmitry
> > That's what i didn't get very clear. If all the deployment steps are
> pre-imaging as that statement says, or every deploy step could be isolated
> and configured somehow.
> > I'm also a bit confused with that spec, because it mixes the concept of
> "deployment steps", will all the changes needed for runtime RAID. Could it
> be possible to separate into two separate ones?
> >
> > - Original Message -
> > From: "Dmitry Tantsur" <dtant...@redhat.com>
> > To: openstack-dev@lists.openstack.org
> > Sent: Friday, December 2, 2016 3:51:30 PM
> > Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel
> parameters on local boot
> >
> > On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:
> >> Hi Dmitry
> >>
> >> So we've been looking at that spec you suggested, but we are wondering
> if that will be useful for our use case. As the text says:
> >>
> >> The ``ironic-python-agent`` project and ``agent`` driver will be
> adjusted to
> >> support ``get_deploy_steps``. That way, ``ironic-python-agent`` will be
> able
> >> to declare deploy steps to run prior to disk imaging, and operators
> will be
> >> able to extend ``ironic-python-agent`` to add any custom step.
> >>
> >> Our needs are different, actually we need to create a deployment step
> after imaging. We'd need an step that drops config on /etc/default/grub ,
> and updates it. This is a post-imaging deploy step, that modifies the base
> image. Could ironic support these kind of steps, if there is a base system
> to just define per-user steps?
> >
> > I thought that all deployment operations are converted to steps, with
> > partitioning, writing the image, writing the configdrive and installing
> the boot
> > loader being four default ones (as you see, two steps actually happen
> after the
> > image is written).
> >
> >>
> >> The idea we had on mind is:
> >> - from tripleo, add a property to each flavor, that defines the boot
> parameters:  openstack flavor set compute --property
> os:kernel_boot_params='abc'
> >> - define a "ironic post-imaging deploy step", that will grab this
> property from the flavor, drop it on /etc/default/grub and regenerate it
> >> - then on local boot, the proper kernel parameters will be applied
> >>
> 

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Hi , Dmitry
That's what i didn't get very clear. If all the deployment steps are 
pre-imaging as that statement says, or every deploy step could be isolated and 
configured somehow.
I'm also a bit confused with that spec, because it mixes the concept of 
"deployment steps", will all the changes needed for runtime RAID. Could it be 
possible to separate into two separate ones?

- Original Message -
From: "Dmitry Tantsur" <dtant...@redhat.com>
To: openstack-dev@lists.openstack.org
Sent: Friday, December 2, 2016 3:51:30 PM
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel 
parameters on local boot

On 12/02/2016 01:28 PM, Yolanda Robla Mota wrote:
> Hi Dmitry
>
> So we've been looking at that spec you suggested, but we are wondering if 
> that will be useful for our use case. As the text says:
>
> The ``ironic-python-agent`` project and ``agent`` driver will be adjusted to
> support ``get_deploy_steps``. That way, ``ironic-python-agent`` will be able
> to declare deploy steps to run prior to disk imaging, and operators will be
> able to extend ``ironic-python-agent`` to add any custom step.
>
> Our needs are different, actually we need to create a deployment step after 
> imaging. We'd need an step that drops config on /etc/default/grub , and 
> updates it. This is a post-imaging deploy step, that modifies the base image. 
> Could ironic support these kind of steps, if there is a base system to just 
> define per-user steps?

I thought that all deployment operations are converted to steps, with 
partitioning, writing the image, writing the configdrive and installing the 
boot 
loader being four default ones (as you see, two steps actually happen after the 
image is written).

>
> The idea we had on mind is:
> - from tripleo, add a property to each flavor, that defines the boot 
> parameters:  openstack flavor set compute --property 
> os:kernel_boot_params='abc'
> - define a "ironic post-imaging deploy step", that will grab this property 
> from the flavor, drop it on /etc/default/grub and regenerate it
> - then on local boot, the proper kernel parameters will be applied
>
> What is your feedback there?
>
> - Original Message -
> From: "Dmitry Tantsur" <dtant...@redhat.com>
> To: openstack-dev@lists.openstack.org
> Sent: Friday, December 2, 2016 12:44:29 PM
> Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel 
> parameters on local boot
>
> On 11/28/2016 04:46 PM, Jay Faulkner wrote:
>>
>>> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota <yrobl...@redhat.com> wrote:
>>>
>>> Hi, good afternoon
>>>
>>> I wanted to start an email thread about how to properly setup kernel 
>>> parameters on local boot, for our overcloud images on TripleO.
>>> These parameters may vary depending on the needs of our end users, and even 
>>> can be different ( for different roles ) per deployment. As an example, we 
>>> need it for:
>>> - enable FIPS kernel in terms of security 
>>> (https://bugs.launchpad.net/tripleo/+bug/1640235)
>>> - enable functionality for DPDK/SR-IOV 
>>> (https://review.openstack.org/#/c/331564/)
>>> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
>>> - etc..
>>>
>>> So far, the solutions we got were on several directions:
>>>
>>> 1. Update the golden overcloud-full image with virt-customize, modifying 
>>> /etc/default/grub settings according to our needs: this is a manual 
>>> process, not really driven by TripleO. End users will want to avoid manual 
>>> steps as much as possible. Also if we announce that OpenStack ships 
>>> features in TripleO like DPDK, SR-IOV... doesn't make sense to tell end 
>>> users that if they want to consume that feature, they need to do manual 
>>> updates on the image. It shall be natively supported, or configurable per 
>>> TripleO environments.
>>>
>>> 2. Create our own images using diskimage-builder and custom elements: in 
>>> this case, we have the problem that the partners will loose support, as 
>>> building their own images is good for upstream, but not accepted into the 
>>> OSP environment. Also the combination of images needed can be huge, that 
>>> can be a blocker for QA.
>>>
>>> 3. Add Ironic support for it. Images can be uploaded to glance, and some 
>>> properties can be set on metadata, like a json with kernel parameters. 
>>> Ironic will modify these kernel parameters when deploying the image (in a 
>>> similar way that when it installs bootloader, or generates partitions).
>>>
>>
&g

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Yes, we are talking about physical hardware and large clusters. Also in a very 
demanding environment.
So reboots are really suboptimal in that case.

- Original Message -
From: "Alex Schultz" <aschu...@redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Sent: Friday, December 2, 2016 3:38:53 PM
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel 
parameters on local boot

On Fri, Dec 2, 2016 at 7:29 AM, Oliver Walsh <owa...@redhat.com> wrote:
> Hi Yolanda,
>
> I've the same requirements for a real-time compute role.
>
> I'm current using #4. Puppet sets the kernel cmdline in
> /etc/defaults/grub, then touches a file that triggers a reboot in an
> os-refresh-config post-configure script.
>
> How much of an issue is the reboot? In my dev env it doesn't make a
> significant difference to the overall deployment time of a node.
>

If this is physical hardware, the reboot can add 5-10+ minutes
depending on the vendor.  VM's aren't a good representation of the
actual cost of a reboot.

Thanks,
-Alex

> I'm thinking we could use #4 as the general solution. In cases where a
> reboot is too expensive then #1/#2/#3 could be used to prime the image
> with same /etc/default/grub that puppet would create. As puppet
> doesn't change it doesn't trigger a reboot.
>
>
> Re custom images. Support in python-tripleoclient could be improved
> but for now this is what I'm doing:
>
> Uploading a custom image:
> OS_IMAGE=custom-overcloud-full.qcow2 openstack overcloud image upload
>
> Set the Image for the custom role in param_defaults:
> parameter_defaults:
>   CustomRoleImage: custom-overcloud-full
>
> Thanks,
> Ollie
>
> On 28 November 2016 at 15:36, Yolanda Robla Mota <yrobl...@redhat.com> wrote:
>> Hi, good afternoon
>>
>> I wanted to start an email thread about how to properly setup kernel 
>> parameters on local boot, for our overcloud images on TripleO.
>> These parameters may vary depending on the needs of our end users, and even 
>> can be different ( for different roles ) per deployment. As an example, we 
>> need it for:
>> - enable FIPS kernel in terms of security 
>> (https://bugs.launchpad.net/tripleo/+bug/1640235)
>> - enable functionality for DPDK/SR-IOV 
>> (https://review.openstack.org/#/c/331564/)
>> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
>> - etc..
>>
>> So far, the solutions we got were on several directions:
>>
>> 1. Update the golden overcloud-full image with virt-customize, modifying 
>> /etc/default/grub settings according to our needs: this is a manual process, 
>> not really driven by TripleO. End users will want to avoid manual steps as 
>> much as possible. Also if we announce that OpenStack ships features in 
>> TripleO like DPDK, SR-IOV... doesn't make sense to tell end users that if 
>> they want to consume that feature, they need to do manual updates on the 
>> image. It shall be natively supported, or configurable per TripleO 
>> environments.
>>
>> 2. Create our own images using diskimage-builder and custom elements: in 
>> this case, we have the problem that the partners will loose support, as 
>> building their own images is good for upstream, but not accepted into the 
>> OSP environment. Also the combination of images needed can be huge, that can 
>> be a blocker for QA.
>>
>> 3. Add Ironic support for it. Images can be uploaded to glance, and some 
>> properties can be set on metadata, like a json with kernel parameters. 
>> Ironic will modify these kernel parameters when deploying the image (in a 
>> similar way that when it installs bootloader, or generates partitions).
>>
>> 4. Configure it post-deployment: there can be some puppet element that 
>> updates kernel parameters. But it will need a node reboot to be applied, and 
>> it's very far from being optimal and acceptable for the end users. Reboots 
>> are slow, they can be a problem depending on the number of nodes/hardware, 
>> and also the timing of reboot shall be totally controlled (after all puppet 
>> has been applied properly).
>>
>>
>> In the first three cases, we also hit the problem that TripleO only accepts 
>> one single overcloud image for all deployments - there is no way to instruct 
>> TripleO to upload and use several images, depending on the node type 
>> (although Ironic supports it). Also, we are worried about upgrade paths if 
>> we do image customizations. We need a clear way to move forward on it.
>>
>> So, we'd like to discuss the possible options there 

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Hi Dmitry

So we've been looking at that spec you suggested, but we are wondering if that 
will be useful for our use case. As the text says:

The ``ironic-python-agent`` project and ``agent`` driver will be adjusted to
support ``get_deploy_steps``. That way, ``ironic-python-agent`` will be able
to declare deploy steps to run prior to disk imaging, and operators will be
able to extend ``ironic-python-agent`` to add any custom step.

Our needs are different, actually we need to create a deployment step after 
imaging. We'd need an step that drops config on /etc/default/grub , and updates 
it. This is a post-imaging deploy step, that modifies the base image. Could 
ironic support these kind of steps, if there is a base system to just define 
per-user steps?

The idea we had on mind is:
- from tripleo, add a property to each flavor, that defines the boot 
parameters:  openstack flavor set compute --property os:kernel_boot_params='abc'
- define a "ironic post-imaging deploy step", that will grab this property from 
the flavor, drop it on /etc/default/grub and regenerate it
- then on local boot, the proper kernel parameters will be applied

What is your feedback there?

- Original Message -
From: "Dmitry Tantsur" <dtant...@redhat.com>
To: openstack-dev@lists.openstack.org
Sent: Friday, December 2, 2016 12:44:29 PM
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel 
parameters on local boot

On 11/28/2016 04:46 PM, Jay Faulkner wrote:
>
>> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota <yrobl...@redhat.com> wrote:
>>
>> Hi, good afternoon
>>
>> I wanted to start an email thread about how to properly setup kernel 
>> parameters on local boot, for our overcloud images on TripleO.
>> These parameters may vary depending on the needs of our end users, and even 
>> can be different ( for different roles ) per deployment. As an example, we 
>> need it for:
>> - enable FIPS kernel in terms of security 
>> (https://bugs.launchpad.net/tripleo/+bug/1640235)
>> - enable functionality for DPDK/SR-IOV 
>> (https://review.openstack.org/#/c/331564/)
>> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
>> - etc..
>>
>> So far, the solutions we got were on several directions:
>>
>> 1. Update the golden overcloud-full image with virt-customize, modifying 
>> /etc/default/grub settings according to our needs: this is a manual process, 
>> not really driven by TripleO. End users will want to avoid manual steps as 
>> much as possible. Also if we announce that OpenStack ships features in 
>> TripleO like DPDK, SR-IOV... doesn't make sense to tell end users that if 
>> they want to consume that feature, they need to do manual updates on the 
>> image. It shall be natively supported, or configurable per TripleO 
>> environments.
>>
>> 2. Create our own images using diskimage-builder and custom elements: in 
>> this case, we have the problem that the partners will loose support, as 
>> building their own images is good for upstream, but not accepted into the 
>> OSP environment. Also the combination of images needed can be huge, that can 
>> be a blocker for QA.
>>
>> 3. Add Ironic support for it. Images can be uploaded to glance, and some 
>> properties can be set on metadata, like a json with kernel parameters. 
>> Ironic will modify these kernel parameters when deploying the image (in a 
>> similar way that when it installs bootloader, or generates partitions).
>>
>
> This has been proposed before in ironic-specs 
> (https://review.openstack.org/#/c/331564/) and was rejected, as it would 
> require Ironic to reach out and modify image contents, which traditionally 
> has been considered out of scope for Ironic. I would personally recommend #4, 
> as post-boot automation is the safest way to configure node-specific options 
> inside an image.

I'm still a bit divided about our decision back then.. On one hand, this does 
seem somewhat out of scope. On the other, I quite understand why reboot is 
suboptimal. I wonder if the ongoing deploy steps work will actually solve it by 
allowing hardware managers to provide additional deploy steps.

Yolanda, you may want to check the spec 
https://review.openstack.org/#/c/382091/ 
as it lays the foundation for the deploy steps idea.

>
> Thanks,
> Jay Faulkner
> OSIC
>
>
>> 4. Configure it post-deployment: there can be some puppet element that 
>> updates kernel parameters. But it will need a node reboot to be applied, and 
>> it's very far from being optimal and acceptable for the end users. Reboots 
>> are slow, they can be a problem depending on the number of nodes/hardware, 
>> and also the timing of reboot shall be total

Re: [openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

The problem we have with that is that for changes to take effect we will need a 
reboot after it.
This is suboptimal for production environments, where there are large amount of 
nodes and with an slow hardware. And also the reboot needs to be carefully 
synced, to only take place after all puppet changes have been applied.
That's why we wanted to consider some other solutions that are done 
pre-deployment, they will be much more effective in terms of performance.

- Original Message -
From: "Jay Faulkner" <j...@jvf.cc>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Sent: Monday, November 28, 2016 4:46:56 PM
Subject: Re: [openstack-dev] [tripleo] [ironic] Need to update kernel 
parameterson local boot


> On Nov 28, 2016, at 7:36 AM, Yolanda Robla Mota <yrobl...@redhat.com> wrote:
> 
> Hi, good afternoon
> 
> I wanted to start an email thread about how to properly setup kernel 
> parameters on local boot, for our overcloud images on TripleO.
> These parameters may vary depending on the needs of our end users, and even 
> can be different ( for different roles ) per deployment. As an example, we 
> need it for:
> - enable FIPS kernel in terms of security 
> (https://bugs.launchpad.net/tripleo/+bug/1640235)
> - enable functionality for DPDK/SR-IOV 
> (https://review.openstack.org/#/c/331564/)
> - enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
> - etc..
> 
> So far, the solutions we got were on several directions:
> 
> 1. Update the golden overcloud-full image with virt-customize, modifying 
> /etc/default/grub settings according to our needs: this is a manual process, 
> not really driven by TripleO. End users will want to avoid manual steps as 
> much as possible. Also if we announce that OpenStack ships features in 
> TripleO like DPDK, SR-IOV... doesn't make sense to tell end users that if 
> they want to consume that feature, they need to do manual updates on the 
> image. It shall be natively supported, or configurable per TripleO 
> environments.
> 
> 2. Create our own images using diskimage-builder and custom elements: in this 
> case, we have the problem that the partners will loose support, as building 
> their own images is good for upstream, but not accepted into the OSP 
> environment. Also the combination of images needed can be huge, that can be a 
> blocker for QA.
> 
> 3. Add Ironic support for it. Images can be uploaded to glance, and some 
> properties can be set on metadata, like a json with kernel parameters. Ironic 
> will modify these kernel parameters when deploying the image (in a similar 
> way that when it installs bootloader, or generates partitions).
> 

This has been proposed before in ironic-specs 
(https://review.openstack.org/#/c/331564/) and was rejected, as it would 
require Ironic to reach out and modify image contents, which traditionally has 
been considered out of scope for Ironic. I would personally recommend #4, as 
post-boot automation is the safest way to configure node-specific options 
inside an image.

Thanks,
Jay Faulkner
OSIC


> 4. Configure it post-deployment: there can be some puppet element that 
> updates kernel parameters. But it will need a node reboot to be applied, and 
> it's very far from being optimal and acceptable for the end users. Reboots 
> are slow, they can be a problem depending on the number of nodes/hardware, 
> and also the timing of reboot shall be totally controlled (after all puppet 
> has been applied properly).
> 
> 
> In the first three cases, we also hit the problem that TripleO only accepts 
> one single overcloud image for all deployments - there is no way to instruct 
> TripleO to upload and use several images, depending on the node type 
> (although Ironic supports it). Also, we are worried about upgrade paths if we 
> do image customizations. We need a clear way to move forward on it.
> 
> So, we'd like to discuss the possible options there and the action items to 
> take (raise bugs, create some blueprints...). To summarize, our end goal is 
> the following:
> 
> - need to map overcloud-full images to roles
> - need to be done in an automated way, no manual steps enforced, and in a way 
> that can pass properly quality controls
> - reboots are sub-optimal
> 
> What are your thoughts there?
> 
> Best,
> 
> 
> Yolanda Robla
> yrobl...@redhat.com
> Principal Software Engineer - NFV Partner 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

[openstack-dev] [tripleo] [ironic] Need to update kernel parameters on local boot

[Yolanda Robla Mota]

Hi, good afternoon

I wanted to start an email thread about how to properly setup kernel parameters 
on local boot, for our overcloud images on TripleO.
These parameters may vary depending on the needs of our end users, and even can 
be different ( for different roles ) per deployment. As an example, we need it 
for:
- enable FIPS kernel in terms of security 
(https://bugs.launchpad.net/tripleo/+bug/1640235)
- enable functionality for DPDK/SR-IOV 
(https://review.openstack.org/#/c/331564/)
- enable rd.iscsi.firmware=1 flag (this for the ramdisk image)
- etc..

So far, the solutions we got were on several directions:

1. Update the golden overcloud-full image with virt-customize, modifying 
/etc/default/grub settings according to our needs: this is a manual process, 
not really driven by TripleO. End users will want to avoid manual steps as much 
as possible. Also if we announce that OpenStack ships features in TripleO like 
DPDK, SR-IOV... doesn't make sense to tell end users that if they want to 
consume that feature, they need to do manual updates on the image. It shall be 
natively supported, or configurable per TripleO environments.

2. Create our own images using diskimage-builder and custom elements: in this 
case, we have the problem that the partners will loose support, as building 
their own images is good for upstream, but not accepted into the OSP 
environment. Also the combination of images needed can be huge, that can be a 
blocker for QA.

3. Add Ironic support for it. Images can be uploaded to glance, and some 
properties can be set on metadata, like a json with kernel parameters. Ironic 
will modify these kernel parameters when deploying the image (in a similar way 
that when it installs bootloader, or generates partitions).

4. Configure it post-deployment: there can be some puppet element that updates 
kernel parameters. But it will need a node reboot to be applied, and it's very 
far from being optimal and acceptable for the end users. Reboots are slow, they 
can be a problem depending on the number of nodes/hardware, and also the timing 
of reboot shall be totally controlled (after all puppet has been applied 
properly).


In the first three cases, we also hit the problem that TripleO only accepts one 
single overcloud image for all deployments - there is no way to instruct 
TripleO to upload and use several images, depending on the node type (although 
Ironic supports it). Also, we are worried about upgrade paths if we do image 
customizations. We need a clear way to move forward on it.

So, we'd like to discuss the possible options there and the action items to 
take (raise bugs, create some blueprints...). To summarize, our end goal is the 
following:

- need to map overcloud-full images to roles
- need to be done in an automated way, no manual steps enforced, and in a way 
that can pass properly quality controls
- reboots are sub-optimal

What are your thoughts there?

Best,


Yolanda Robla
yrobl...@redhat.com
Principal Software Engineer - NFV Partner 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

[openstack-dev] [tripleo] [tripleo-quickstart] Tripleo-Quickstart root privileges

[Yolanda Robla Mota]

Hi all
I wanted to start a thread about the current privileges model for TripleO 
quickstart.
Currently there is the assumption that quickstart does not need root privileges 
after the environment and provision roles. However, this assumption cannot be 
valid for several use cases.
In particular, I have the need of creating working directories outside the home 
directory of the user running quickstart. This can be useful on environments 
where /home partition is small and cannot be modified (so there is not enough 
disk space to host TripleO quickstart artifacts there).
This is the change i'm working on for that use case: 
https://review.openstack.org/#/c/384892

As you can see, to be able to create working directories outside home 
directories, it will need root privileges to properly create the initial 
working dir and give proper permissions. This break current model but I think 
it could provide advantages and flexibility to the deployment. So what are your 
thoughts about it, shall we continue with that and change privileges model? The 
alternative I can see is to just limit the working directory to home directory, 
but then do not offer the ability to customize it, and document that 
restriction on TripleO quickstart properly.

Best

Yolanda Robla
yrobl...@redhat.com
Principal Software Engineer - NFV Partner 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

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

[Yolanda Robla Mota]

Thanks Emilien for all the work you've done on the modules, and thanks for 
always being there when support was needed.
I think you've done an amazing work as PTL, and good luck on your next projects!

- Original Message -
From: "Emilien Macchi" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, September 9, 2016 6:25:56 PM
Subject: Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

On Fri, Sep 9, 2016 at 12:14 PM, Denis Egorenko  wrote:
> Hey Emilien,
>
> It was a big pleasure to work with you!
>
> Thank you for all your help! :) And good luck on your next project and
> activities!

I don't have any next project :-) I just think we should have a new
PTL this time.
Sorry, but I'll keep bother you for long time :-P

> 2016-09-09 19:05 GMT+03:00 Emilien Macchi :
>>
>> Hi,
>>
>> I wrote a little blog post about the last cycle in PuppetOpenStack:
>> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>>
>> I can't describe how much I liked to be PTL during the last 18 months
>> and I wouldn't imagine we would be where we are today when I started
>> to contribute on this project.
>> Working on it is something I really enjoy because we have interactions
>> with all OpenStack community and I can't live without it.
>>
>> However, I think it's time to pass the PTL torch for Ocata cycle.
>> Don't worry, I'll still be around and bother you when CI is broken ;-)
>>
>> Again, a big thank you for those who work with me,
>> --
>> 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
>
>
>
>
> --
> Best Regards,
> Egorenko Denis,
> Senior Deployment Engineer
> 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
>



-- 
Emilien Macchi

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

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

[openstack-dev] [openstack-infra] Gerrit server replacement scheduled for April 11th

[Yolanda Robla Mota]

Hello from Infra.

This is another reminder for the future Gerrit maintenance, scheduled for 
Monday, April 11, 2016 20:00 UTC.
At this time, the OpenStack Project Infrastructure team will be increasing the 
memory on
the server which review.openstack.org runs, and that means a new virtual 
machine instance with new IP
addresses assigned by our service provider. As announced before, the new IP 
addresses will be as follows:

IPv4 -> 104.130.246.91
IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525

They will replace these current production IP addresses:

 IPv4 -> 104.130.159.134
 IPv6 -> 2001:4800:7818:102:be76:4eff:fe05:9b12

We understand that some users may be running from egress-filtered
networks with port 29418/tcp explicitly allowed to the current
review.openstack.org IP addresses, and so are providing this
information as far in advance as we can to allow them time to update
their firewalls accordingly.

Note that some users dealing with egress filtering may find it
easier to switch their local configuration to use Gerrit's REST API
via HTTPS instead, and the current release of git-review has support
for that workflow as well.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

Best,

--
Yolanda Robla Mota
OpenStack Engineer
+34 605641639
yolanda.robla-m...@hpe.com


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

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

[Yolanda Robla Mota]

So the advantages I can see with diskimage-builder are:
- we reuse the same tooling that is present in other openstack projects 
to generate images, rather than relying on an external image
- it improves the control we have on the contents of the image, instead 
of seeing that as a black box. At the moment we can rely on the default 
tree for fedora 23, but this can be updated per magnum needs
- reusability: we have atomic 23 now, but why not create magnum images 
with dib, for ubuntu, or any other distros ? Relying on 
diskimage-builder makes it easy and flexible, because it's a matter of 
adding the right elements.


Best
Yolanda

El 29/03/16 a las 21:54, Steven Dake (stdake) escribió:

Adrian,

Makes sense.  Do the images have to be built to be mirrored though?  Can't
they just be put on the mirror sites fro upstream?

Thanks
-steve

On 3/29/16, 11:02 AM, "Adrian Otto" <adrian.o...@rackspace.com> wrote:


Steve,

I¹m very interested in having an image locally cached in glance in each
of the clouds used by OpenStack infra. The local caching of the glance
images will produce much faster gate testing times. I don¹t care about
how the images are built, but we really do care about the performance
outcome.

Adrian


On Mar 29, 2016, at 10:38 AM, Steven Dake (stdake) <std...@cisco.com>
wrote:

Yolanda,

That is a fantastic objective.  Matthieu asked why build our own images
if
the upstream images work and need no further customization?

Regards
-steve

On 3/29/16, 1:57 AM, "Yolanda Robla Mota" <yolanda.robla-m...@hpe.com>
wrote:


Hi
The idea is to build own images using diskimage-builder, rather than
downloading the image from external sources. By that way, the image can
live in our mirrors, and is built using the same pattern as other
images
used in OpenStack.
It also opens the door to customize the images, using custom trees, if
there is a need for it. Actually we rely on official tree for Fedora 23
Atomic (https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/) as
default.

Best,
Yolanda

El 29/03/16 a las 10:17, Mathieu Velten escribió:

Hi,

We are using the official Fedora Atomic 23 images here (on Mitaka M1
however) and it seems to work fine with at least Kubernetes and Docker
Swarm.
Any reason to continue building specific Magnum image ?

Regards,

Mathieu

Le mercredi 23 mars 2016 à 12:09 +0100, Yolanda Robla Mota a écrit :

Hi
I wanted to start a discussion on how Fedora Atomic images are being
built. Currently the process for generating the atomic images used
on
Magnum is described here:
http://docs.openstack.org/developer/magnum/dev/build-atomic-image.htm
l.
The image needs to be built manually, uploaded to fedorapeople, and
then
consumed from there in the magnum tests.
I have been working on a feature to allow diskimage-builder to
generate
these images. The code that makes it possible is here:
https://review.openstack.org/287167
This will allow that magnum images are generated on infra, using
diskimage-builder element. This element also has the ability to
consume
any tree we need, so images can be customized on demand. I generated
one
image using this element, and uploaded to fedora people. The image
has
passed tests, and has been validated by several people.

So i'm raising that topic to decide what should be the next steps.
This
change to generate fedora-atomic images has not already landed into
diskimage-builder. But we have two options here:
- add this element to generic diskimage-builder elements, as i'm
doing now
- generate this element internally on magnum. So we can have a
directory
in magnum project, called "elements", and have the fedora-atomic
element
here. This will give us more control on the element behaviour, and
will
allow to update the element without waiting for external reviews.

Once the code for diskimage-builder has landed, another step can be
to
periodically generate images using a magnum job, and upload these
images
to OpenStack Infra mirrors. Currently the image is based on Fedora
F23,
docker-host tree. But different images can be generated if we need a
better option.

As soon as the images are available on internal infra mirrors, the
tests
can be changed, to consume these internals images. By this way the
tests
can be a bit faster (i know that the bottleneck is on the functional
testing, but if we reduce the download time it can help), and tests
can
be more reilable, because we will be removing an external dependency.

So i'd like to get more feedback on this topic, options and next
steps
to achieve the goals. Best



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

--
Yolanda Robla Mota
Cloud Automation and Distribution E

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

[Yolanda Robla Mota]

Hi
The idea is to build own images using diskimage-builder, rather than 
downloading the image from external sources. By that way, the image can 
live in our mirrors, and is built using the same pattern as other images 
used in OpenStack.
It also opens the door to customize the images, using custom trees, if 
there is a need for it. Actually we rely on official tree for Fedora 23 
Atomic (https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/) as 
default.


Best,
Yolanda

El 29/03/16 a las 10:17, Mathieu Velten escribió:

Hi,

We are using the official Fedora Atomic 23 images here (on Mitaka M1
however) and it seems to work fine with at least Kubernetes and Docker
Swarm.
Any reason to continue building specific Magnum image ?

Regards,

Mathieu

Le mercredi 23 mars 2016 à 12:09 +0100, Yolanda Robla Mota a écrit :

Hi
I wanted to start a discussion on how Fedora Atomic images are being
built. Currently the process for generating the atomic images used
on
Magnum is described here:
http://docs.openstack.org/developer/magnum/dev/build-atomic-image.htm
l.
The image needs to be built manually, uploaded to fedorapeople, and
then
consumed from there in the magnum tests.
I have been working on a feature to allow diskimage-builder to
generate
these images. The code that makes it possible is here:
https://review.openstack.org/287167
This will allow that magnum images are generated on infra, using
diskimage-builder element. This element also has the ability to
consume
any tree we need, so images can be customized on demand. I generated
one
image using this element, and uploaded to fedora people. The image
has
passed tests, and has been validated by several people.

So i'm raising that topic to decide what should be the next steps.
This
change to generate fedora-atomic images has not already landed into
diskimage-builder. But we have two options here:
- add this element to generic diskimage-builder elements, as i'm
doing now
- generate this element internally on magnum. So we can have a
directory
in magnum project, called "elements", and have the fedora-atomic
element
here. This will give us more control on the element behaviour, and
will
allow to update the element without waiting for external reviews.

Once the code for diskimage-builder has landed, another step can be
to
periodically generate images using a magnum job, and upload these
images
to OpenStack Infra mirrors. Currently the image is based on Fedora
F23,
docker-host tree. But different images can be generated if we need a
better option.

As soon as the images are available on internal infra mirrors, the
tests
can be changed, to consume these internals images. By this way the
tests
can be a bit faster (i know that the bottleneck is on the functional
testing, but if we reduce the download time it can help), and tests
can
be more reilable, because we will be removing an external dependency.

So i'd like to get more feedback on this topic, options and next
steps
to achieve the goals. Best


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


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.com


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

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

[Yolanda Robla Mota]

I've worked with Julia on bifrost and she is amazing. She also was very 
helpful on debugging Ironic problems, and she has extensive knowledge of 
the system.

Big +1 from me

El 24/03/16 a las 20:34, Chris K escribió:

Big +1 from /me. Juila will be a great addition to the team.

-Chris

On Thu, Mar 24, 2016 at 12:08 PM, Jim Rollenhagen 
<j...@jimrollenhagen.com <mailto:j...@jimrollenhagen.com>> wrote:


Hey all,

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

All in favor say +1 :)

// jim

__
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


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.com

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

Re: [openstack-dev] [magnum] Generate atomic images using diskimage-builder

[Yolanda Robla Mota]

Hi
I have also been talking with diskimage-builder cores and they suggested 
we better start with the element on magnum. So I moved the change here:

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

About diskimage-size, I'll dig a bit more on it. It can be for two causes:
1. To generate the fedora-atomic image, I first install a fedora-minimal 
image, and install ostree packages and the dependencies there. Based on 
that, i execute the ostree commands, and then I update the grub config 
to boot with the new image. But the old contents are still there, so 
this is potentially increasing the size. I will take a look at possible 
cleanup solutions.
2. The way diskimage-builder compresses the image. It can be different 
from the one that Fedora is using, and less effective. I saw discussions 
in diskimage-builder about that, and there have been recent improvements 
as https://review.openstack.org/290944 . Is worth investigating a bit 
more as well.


Best
Yolanda

El 23/03/16 a las 18:10, Ton Ngo escribió:


Hi Yolanda,
Thank you for making a huge improvement from the manual process of 
building the Fedora Atomic image.
Although Atomic does publish a public OpenStack image that is being 
considered in this patch:

https://review.openstack.org/#/c/276232/
in the past we have come to many situations where we need an image 
with specific version of certain software
for features or bug fixes (Kubernetes, Docker, Flannel, ...). So the 
automated and customizable build process

will be very helpful.

With respect to where to land the patch, I think diskimage-builder is 
a reasonable target.
If it does not land there, Magnum does currently have 2 sets of 
diskimage-builder elements for Mesos image
and Ironic image, so it is also reasonable to submit the patch to 
Magnum. With the new push to reorganize
into drivers for COE and distro, the elements would be a natural fit 
for Fedora Atomic.


As for periodic image build, it's a good idea to stay current with the 
distro, but we should avoid the situation
where something new in the image breaks a COE and we are stuck for 
awhile until a fix is made. So instead of
an automated periodic build, we might want to stage the new image to 
make sure it's good before switching.


One question: I notice the image built by DIB is 871MB, similar to the 
manually built image, while the
public image from Atomic is 486MB. It might be worthwhile to 
understand the difference.


Ton Ngo,

Inactive hide details for Yolanda Robla Mota ---03/23/2016 04:12:54 
AM---Hi I wanted to start a discussion on how Fedora AtomicYolanda 
Robla Mota ---03/23/2016 04:12:54 AM---Hi I wanted to start a 
discussion on how Fedora Atomic images are being


From: Yolanda Robla Mota <yolanda.robla-m...@hpe.com>
To: <openstack-dev@lists.openstack.org>
Date: 03/23/2016 04:12 AM
Subject: [openstack-dev] [magnum] Generate atomic images using 
diskimage-builder






Hi
I wanted to start a discussion on how Fedora Atomic images are being
built. Currently the process for generating the atomic images used on
Magnum is described here:
http://docs.openstack.org/developer/magnum/dev/build-atomic-image.html.
The image needs to be built manually, uploaded to fedorapeople, and then
consumed from there in the magnum tests.
I have been working on a feature to allow diskimage-builder to generate
these images. The code that makes it possible is here:
https://review.openstack.org/287167
This will allow that magnum images are generated on infra, using
diskimage-builder element. This element also has the ability to consume
any tree we need, so images can be customized on demand. I generated one
image using this element, and uploaded to fedora people. The image has
passed tests, and has been validated by several people.

So i'm raising that topic to decide what should be the next steps. This
change to generate fedora-atomic images has not already landed into
diskimage-builder. But we have two options here:
- add this element to generic diskimage-builder elements, as i'm doing now
- generate this element internally on magnum. So we can have a directory
in magnum project, called "elements", and have the fedora-atomic element
here. This will give us more control on the element behaviour, and will
allow to update the element without waiting for external reviews.

Once the code for diskimage-builder has landed, another step can be to
periodically generate images using a magnum job, and upload these images
to OpenStack Infra mirrors. Currently the image is based on Fedora F23,
docker-host tree. But different images can be generated if we need a
better option.

As soon as the images are available on internal infra mirrors, the tests
can be changed, to consume these internals images. By this way the tests
can be a bit faster (i know that the bottleneck is on the functional
testing, but if we reduce the download time it can help), and tests can
be 

[openstack-dev] [magnum] Generate atomic images using diskimage-builder

[Yolanda Robla Mota]

Hi
I wanted to start a discussion on how Fedora Atomic images are being 
built. Currently the process for generating the atomic images used on 
Magnum is described here: 
http://docs.openstack.org/developer/magnum/dev/build-atomic-image.html.
The image needs to be built manually, uploaded to fedorapeople, and then 
consumed from there in the magnum tests.
I have been working on a feature to allow diskimage-builder to generate 
these images. The code that makes it possible is here: 
https://review.openstack.org/287167
This will allow that magnum images are generated on infra, using 
diskimage-builder element. This element also has the ability to consume 
any tree we need, so images can be customized on demand. I generated one 
image using this element, and uploaded to fedora people. The image has 
passed tests, and has been validated by several people.


So i'm raising that topic to decide what should be the next steps. This 
change to generate fedora-atomic images has not already landed into 
diskimage-builder. But we have two options here:

- add this element to generic diskimage-builder elements, as i'm doing now
- generate this element internally on magnum. So we can have a directory 
in magnum project, called "elements", and have the fedora-atomic element 
here. This will give us more control on the element behaviour, and will 
allow to update the element without waiting for external reviews.


Once the code for diskimage-builder has landed, another step can be to 
periodically generate images using a magnum job, and upload these images 
to OpenStack Infra mirrors. Currently the image is based on Fedora F23, 
docker-host tree. But different images can be generated if we need a 
better option.


As soon as the images are available on internal infra mirrors, the tests 
can be changed, to consume these internals images. By this way the tests 
can be a bit faster (i know that the bottleneck is on the functional 
testing, but if we reduce the download time it can help), and tests can 
be more reilable, because we will be removing an external dependency.


So i'd like to get more feedback on this topic, options and next steps 
to achieve the goals. Best


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.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-dev] [diskimage-builder] Bypass loopback size limits

[Yolanda Robla Mota]

Hi
I have a problem working with diskimage-builder, when trying to create 
images larger than allowed.


I need to create a dib image, with the following partition (sfdisk format):

2048 4869952 L *
 4872000 + L;
 0 0;
 0 0;

This has been working in the past, but suddenly the config of the VMs i 
was using look different, and i'm getting this error:


Warning: given size (4869952) exceeds max allowable size (3170816)
Warning: The partition table looks like it was made
  for C/H/S=*/69/21 (instead of 197/255/63).
For this listing I'll assume that geometry.
start: (c,h,s) expected (1,28,12) found (0,32,33)
end: (c,h,s) expected (1023,68,21) found (303,68,21)
Warning: partition 2 has size 0 but is not marked Empty
Warning: partition 1 extends past end of disk


Anyone knows how can i bypass that limit on loop device? I tried 
creating an image file with dd, then attaching with losetup (losetup 
/dev/loopxx image-file.img) , but then diskimage-builder complains about 
the filesytem being in use. Anyone has hit that on the pass and knows 
any workaround?


Thanks

--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.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-dev] [Infra] upcoming review.openstack.org IP address change

[Yolanda Robla Mota]

Hello from Infra.

It's that time again... on Monday, April 11, 2016 20:00 UTC, the
OpenStack Project Infrastructure team is increasing the memory on
the server which review.openstack.org runs, and that means a new
virtual machine instance with new IP addresses assigned by our
service provider. The new IP addresses will be as follows:

IPv4 -> 104.130.246.91
IPv6 -> 2001:4800:7819:103:be76:4eff:fe05:8525

They will replace these current production IP addresses:

IPv4 -> 104.130.159.134
IPv6 -> 2001:4800:7818:102:be76:4eff:fe05:9b12

We understand that some users may be running from egress-filtered
networks with port 29418/tcp explicitly allowed to the current
review.openstack.org IP addresses, and so are providing this
information as far in advance as we can to allow them time to update
their firewalls accordingly.

Note that some users dealing with egress filtering may find it
easier to switch their local configuration to use Gerrit's REST API
via HTTPS instead, and the current release of git-review has support
for that workflow as well.
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

We will follow up with final confirmation n subsequent announcements.


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.com


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

Re: [openstack-dev] [all] UNSTABLE jobs - Jenkins failure - do not recheck/approve

[Yolanda Robla Mota]

Thanks Andreas for the support, and apologies for any inconvenience caused.
Best
Yolanda

El 26/01/16 a las 11:24, Andreas Jaeger escribió:

On 2016-01-26 09:41, Andreas Jaeger wrote:

FYI, Jenkins jobs are unstable and failing to upload artifacts, due to a
disk problem on the static server.

Please do not recheck or approve changes for now, they'll just fail...

Yolanda from the infra team is looking at it already,

Everything should be fine again, if not, please tell us on #openstack-infra,

Thanks to Yolanda!

Andreas


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.com


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

Re: [openstack-dev] [stable][horizon] adding stable reviewer

[Yolanda Robla Mota]

Hi Matthias
That group is owned by stable-maint-core
So you should look at members there 
(https://review.openstack.org/#/admin/groups/530,members) and ask some 
of them to add Doug.


Best
Yolanda

El 09/10/15 a las 12:44, Matthias Runge escribió:

Hello,

who would be the person to talk to, to add a new reviewer to
horizon-stable-maint

I would like Doug Fish aka drfish (on launchpad) added.

Unfortunately, the fields on
https://review.openstack.org/#/admin/groups/537,members
are greyed out for me.

Thanks, Matthias

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


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.com


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

Re: [openstack-dev] [Ansible][Infra] Moving ansible roles into big tent?

[Yolanda Robla Mota]

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


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.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