[Gelistirici] mit-kerberos paketi check hatası

[Erdem Bayer]

Selamlar

On Paz, 2011-01-02 at 18:22 +0200, Ozan Çağlayan wrote:
> >
> > * A paketinde bir değişiklik olmuş ise, A paketinin tüm ters
> > bağımlılıklarının bu değişiklikten etkilenip etkilenmedikleri test
> > edilmiyor. Bu testi yapmasını sınırlı kaynağı ve zamanı olan paket
> > sahibinden bekliyoruz.
> 
> Değişikliğe göre değişir. Bu A paketi bir defa kitaplık olmak durumunda. 
> Kitaplık olmadığı durumda A'daki değişikliğin geriye yayılarak sorun 
> çıkarmasını anlamanın tek yolu paketçinin durumdan haberdar olmasıdır.
> 
> A kitaplığının sürümü yükseldiyse, ona bağlanmış paketlerin kırılması 
> durumunda buna yaptığımız bir şey maalesef yok, ancak kırıldıktan sonra 
> sürüm yöneticisi paketçiyi uyarıyor.

Hayır, kitaplık olmak zorunda değil, php paketindeki bir güncelleme
mod_php kullanan bütün paketleri etkileyebilir. Şu anki durumda Php
paketi her güncellendiğinde phpmyadmin paketinin sahibinin paketini yeni
derlenen php ile test etmesini belkiyoruz/istiyoruz, ancak bunu
gerçeklemek mümkün/olanaklı değil.

Paket sahibi paketinin bağımlılıklarında her değişiklik olduğunda
kendisi paketlerini yeniden inşa edip test edecekse, paket inşa etmekten
başka birşey yapmaya vakit bulamayabilir. Halbuki bunun yerine bir paket
güncellendiğinde hem kendisini hem de bütün ters bağımlılıklarını bu işe
tahsis edilmiş bir alanda 3 dağıtım ve iki mimaride inşa etsek,
paketçiye bu inşa edilmiş paketi haber versek, al test et desek herkes
daha verimli çalışmış olmaz mı?

> 
> >
> > * Paketçiden bir pakette yapılan ufak bir değişikliği bile 3 farklı
> > dağıtım ve iki mimari üzerinde kendi başına inşa ve test etmesini
> > bekliyoruz. (Yine sınırlı kaynak ve zaman problemi)
> 
> Buna nasıl bir çözüm bulunabilir bilmiyorum. Sonuçta paketçi bu ufak 
> değişikliği test edecekse zaten 3 farklı dağıtım ve 2 mimarinin 
> halihazırda önünde olması lazım. Bu durumda da pisi bi pspec.xml ile 
> paketi oluşturup kurması çok da zor değil. Ha test etmeyecekse zaten 
> etmiyor ve commit edip geçiyor.

Çok zor değil derken? Bence bayağı zor. Elimizde sınırsız zaman, cpu,
ram olmayabiliyor.

> 
> >
> > * Paket yönetim sistemimizin bir paketi güncellemekten anladığı şey
> > paketin eski sürümünü kaldırıp yeni sürümünü kurmak. Bu durum paketin
> > güncellenme aşamasında yapılması gereken özel birşey varsa elimizi
> > kolumuzu bağlıyor.
> 
> postInstall, preRemove var?

postInstall ve preRemove fonksiyonları paket güncelleme (kaldırıp kurma
değil) aşamasında özel birşey yapılması gerekiyorsa nasıl yardımcı
oluyor? Örneğin bir paket güncellenirken (ama sadece güncellenirken)
yapılması gereken birşey olduğunda postInstall ve preRemove'u nasıl
kullanacağız, açıklanırsa iyi olabilir.

> 
> >
> > * Paket yönetim sistemimiz içinden servis betiği çıkan paketleri servis
> > ile ilgili herhangi bir işlem yapmadan kaldırıyor, daha sonra yeniden
> > kurmaya çalıştığında (örn: güncelleme) karşılaşılan bir hata sistemi
> > geri dönülmez durumda bırakabiliyor. Örn: Paket kaldırıldı, ancak servis
> > durmadığı için yeniden kurulamıyor, artık paket de gittiği için servisi
> > durdurmanın herhangi bir yolu da yoksa ne yapacağımızı şaşırabiliyoruz.
> > (Teorik bir örnek değil, geçen gün eski bir makine üzerinde nfs-server
> > paketini güncellerken başıma geldi.)
> 
> Bundan dolayı oluşan bir sorunla hiç karşılaşmadım şu ana kadar ancak 
> RPM paketlerinde gerçekten de aç/kapa yapılıyor. Bunu mevcut PiSi 
> altyapısıyla yapmak oldukça kolay olmalı.

Ben geçen ay içerisinde iki farklı durumda iki kere karşılaştım, benim
için yeterince sık anlamına geliyor. 

Mevcut pisi altyapısı ile ne kadar kolay olacağını bilmiyorum, ancak
servis durmadı ise paketi kaldırmaması (ve hatta bağımlılıklara da
elleşmemesi, dolayısı ile indirme işleminden sonra ancak tüm
kaldırma/güncelleme işlemlerinden önce çalışması gerekiyor),
güncellemeden önce servis çalışıyor ise güncellemeden sonra da yeniden
çalıştırması gibi gereksinimlere dikkat etmek gerekiyor.

> 
> >
> > * Paketlerimizin farklı mimarilerde farklı ihtiyaçları var ise (örn:
> > farklı bağımlılıklar) bu ihtiyaçları karşılayamıyoruz veya karşılamakta
> > zorlanabiliyoruz.
> 
> Hiç karşılaşmadık. Karşılaşılınca nasıl çözüleceğine dair geliştirici 
> listesi arşivlerinde yapıcı bir tartışma var zaten oradaki çözümlerden 
> birini uygulamak sorunu çözecektir.

Yakın gelecekte üç farklı mimari üzerinde çalışacağız, gerçekten hiç
ihtiyacımız olmayacağından emin miyiz diyorum ben de.

> 
> >
> > Ayrıca yukarıda yazdığın cümle her ne kadar doğru gözükse de yazılan
> > testlerin sadece o paketle ilgili olmadığı, paketin bağımlı olduğu diğer
> > tüm uygulamalar ile o paket arasındaki ilişkiyi de kontrol ettiğini
> > düşündüğümüzde testlerin sadece o paket üzerinde bir değişiklik
> > yapıldığında değil bağımlılıkları içinde bir değişiklik olduğunda da
> > çalıştırılması gerekliliği ortaya çıkıyor, bunu da paketçiye bırakmanın
> > insafsızlık olduğunu düşünüyorum.
> 
> Bu çok over-engineered bir senaryo bence.

Bence değil, sadece şu anda paket sahiplerinden yapmalarını beklediğimiz
bu işi otomatik çalışan bir uygulama yaparsa verim artar, diyorum.

> 
> >
> > Ayrıca testler dışında inşası uzun süren paketler de var, yine bu
> > paketlerde yapılan en ufak değişikliği de 6 ayrı yerde inşa ederek test
> > etmesini paketçiden bekliyoruz, halbuki bunu otomatik yapabilen bir
> > yazılım var ise bu da bana insafsızlık gibi geliyor.
> 
> Evet bu gerçekten hoş olur.
> 
> Bunun için,
> 
> * Dedicated/güçlü bir sunucu altında bir sanallaştırma teknolojisiyle 
> sanallaştırılmış len(dagitim)*len(desteklenen_mimari) kadar derleme 
> çiftliği oluşturulmalı.

Sadece len(dagitim)*len(desteklenen_mimari) kadar derleme çiftliği
yetmez, bu çiftliklerin bu işe (sadece güncellenen paketleri ve ters
bağımlılıklarını inşa etme) işine tahsis edilmiş olmaları gerekir. Bu da
aynı anda çalışabilecek
len(dagitim)*len(desteklenen_mimari)*len(güncelleme gelen paket sayısı)
kadar farm demek. Aynı zamanda şu anda çalışan farmlar da bu işe uygun
değil sanırım, (check aşamalarının atlanması, sadece farm listesine
haber vermesi ancak diğer ilgililere haber vermemesi, ters
bağımlılıkların yeniden inşa edilmemesi), bu tahsis edilen sunucular
için farm programını yeniden düzenlemek veya değiştirmek gerekecektir.

> 
> * Derleme yazılımı kendisine uzaktan gelen istekleri bu çiftliklere 
> paslamalı ve bu çiftliklerde her paketi izole temiz rootfs içinde 
> derlemeli (Sorun 1: A paketi B'nin yeni sürümüne inşa bağımlı ise, A'nın 
> derleneceği ortamda, B'nin yeni sürümü kurulu olmalı. Bu nasıl olacak?).

Başka bir derleme ortamında B'nin yeni sürümünü inşa edecek, A'nın
derleneceği ortamda bu paketi kullanacak.

>  
> Bu esnada testler de çalışmalı.
> 
> * Düzgün bir web arayüz. Ama gerçekten düzgün. Her şeyi anlatan, sunan, 
> test sonuçlarını görüntüleyen, paketleri indiren linklerin olduğu, vs.vs.

Kesinlikle!

> 
> * Paketleri derletme isteklerini göndermek için konsol araç kiti.

Evet, aklımdaki yapı tam bu.

Tüm geliştiricilerin paketlerindeki değişiklikleri derletip sonuçlarını
elde edebilecekleri (sadece sonuçları eposta atmak yetmez, derleme
alanındaki dosyalara bakmak gerekebilir, dolayısı ile ssh veya başka bir
erişim yöntemi de ister), bir geliştirici bir pakette değişiklik yaptığı
zaman belirtilen her mimaride paketi ve tüm ters bağımlılıklarını inşa
edip, pisi dosyasını ve inşa çıktılarını hem değişen paketin sahibine
hem de ters bağımlılıkların sahibine haber vererek gönderen bir sistem
tüm paket sahiplerinin paketleri ile ilgilenirken harcadıkları sürede
ciddi bir tasarruf sağlayacaktır.

Yukarıdaki tanıma ekleyecek birşeyi olan var mı? (bu işin amacı ve
gerçeklemesi gereken ihtiyaç listesi ortaya çıkıyor...)

Saygılarımla
Erdem Bayer